Протокол TLS 1.2

TLS 1.2 (Transport Layer Security 1.2) — это версия криптографического протокола, обеспечивающего защищённую передачу данных между двумя узлами в компьютерной сети, преимущественно между веб-сервером и браузером. Протокол TLS 1.2 был разработан организацией IETF (Internet Engineering Task Force) и опубликован в августе 2008 года в документе RFC 5246, заменив предыдущую версию TLS 1.1. TLS 1.2 обеспечивает конфиденциальность, целостность и аутентификацию данных путём шифрования, проверки целостности сообщений и проверки подлинности сторон с помощью цифровых сертификатов. На протяжении 2010-х годов протокол TLS 1.2 являлся де-факто стандартом безопасности в интернете, однако к началу 2020-х годов начал вытесняться более современной версией TLS 1.3.

История

Предпосылки создания

Предшественником TLS 1.2 был протокол SSL (Secure Sockets Layer), разработанный компанией Netscape в 1994 году. После выхода SSL 3.0 в 1996 году IETF стандартизировала его как TLS 1.0 (RFC 2246, 1999 год). TLS 1.1 (RFC 4346, 2006 год) внёс незначительные улучшения, в частности защиту от атак на основе CBC (Cipher Block Chaining). Однако к середине 2000-х годов были выявлены уязвимости в криптографических алгоритмах, поддерживаемых TLS 1.0 и 1.1, что потребовало разработки новой версии.

Разработка и принятие

Рабочая группа IETF по транспортной безопасности (TLS WG) начала работу над TLS 1.2 в 2007 году. Основной целью было удаление устаревших и небезопасных криптографических примитивов, а также введение более гибкой системы согласования алгоритмов. В августе 2008 года был опубликован RFC 5246, официально описывающий TLS 1.2. Протокол быстро получил поддержку со стороны крупных разработчиков программного обеспечения, включая Microsoft, Mozilla и Google. В 2011 году NIST (Национальный институт стандартов и технологий США) рекомендовал переход на TLS 1.2 для государственных учреждений.

Вытеснение TLS 1.3

В 2018 году IETF опубликовала TLS 1.3 (RFC 8446), который был значительно быстрее и безопаснее, так как сократил количество этапов рукопожатия и удалил устаревшие алгоритмы. Однако TLS 1.2 оставался широко используемым из-за обратной совместимости и поддержки в старых системах. По состоянию на 2024 год многие крупные сайты и сервисы (например, Google, Яндекс, VK) продолжают поддерживать TLS 1.2 наряду с TLS 1.3, хотя доля TLS 1.2 в интернет-трафике постепенно снижается.

Архитектура и принцип работы

Место в модели OSI

TLS 1.2 работает на транспортном уровне (уровень 4) модели OSI, располагаясь между прикладным протоколом (например, HTTP) и транспортным протоколом (TCP). Он не является самостоятельным протоколом, а представляет собой надстройку, которая шифрует данные прикладного уровня перед отправкой по TCP.

Два подслоя

Протокол TLS 1.2 состоит из двух подслоев:

• Рукопожатие (Handshake) — отвечает за установление защищённого соединения, согласование криптографических параметров и аутентификацию сторон.
• Запись (Record) — отвечает за шифрование, дешифрование и проверку целостности передаваемых данных.

Рукопожатие TLS 1.2

Процесс рукопожатия в TLS 1.2 включает несколько этапов:

1. ClientHello — клиент отправляет серверу список поддерживаемых версий TLS, набор шифров (Cipher Suites), случайное число (Client Random) и опционально расширения.
2. ServerHello — сервер выбирает версию TLS, набор шифров и отправляет своё случайное число (Server Random), а также свой цифровой сертификат.
3. ServerKeyExchange (опционально) — если выбранный набор шифров требует обмена ключами (например, Diffie-Hellman), сервер отправляет соответствующие параметры.
4. CertificateRequest (опционально) — сервер может запросить сертификат клиента для взаимной аутентификации.
5. ServerHelloDone — сервер сообщает, что завершил отправку параметров.
6. ClientKeyExchange — клиент генерирует предварительный главный секрет (Pre-Master Secret) и отправляет его серверу, зашифрованным открытым ключом сервера (из сертификата) или с использованием протокола Diffie-Hellman.
7. ChangeCipherSpec — обе стороны подтверждают переход на согласованные параметры шифрования.
8. Finished — обе стороны отправляют зашифрованное сообщение, содержащее хеш всех предыдущих сообщений, для проверки целостности рукопожатия.

После завершения рукопожатия начинается защищённая передача данных.

Наборы шифров (Cipher Suites)

TLS 1.2 поддерживает множество комбинаций алгоритмов, которые определяются в наборе шифров. Типичный набор шифров включает:

• Алгоритм обмена ключами (например, RSA, Diffie-Hellman, ECDHE).
• Алгоритм аутентификации (например, RSA, DSA, ECDSA).
• Алгоритм шифрования (например, AES, 3DES, RC4).
• Алгоритм контроля целостности (например, HMAC-SHA256, HMAC-SHA1).

Пример: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 — использует эллиптическую кривую Диффи-Хеллмана (ECDHE) для обмена ключами, RSA для аутентификации, AES-256 в режиме GCM для шифрования и SHA-384 для HMAC.

Криптографические алгоритмы

Симметричное шифрование

TLS 1.2 поддерживает несколько алгоритмов симметричного шифрования:

• AES (Advanced Encryption Standard) — наиболее распространённый, с длиной ключа 128 или 256 бит, в режимах CBC, GCM или CCM.
• 3DES (Triple DES) — устаревший, с 112-битным ключом, не рекомендуется из-за низкой производительности и уязвимости к атаке Sweet32.
• RC4 — потоковый шифр, удалён из рекомендаций из-за серьёзных уязвимостей (атака RC4 biases). В RFC 7465 (2015 год) использование RC4 в TLS было запрещено.
• ChaCha20 — современный потоковый шифр, добавленный в TLS 1.2 через расширения (RFC 7905, 2016 год).

Асимметричное шифрование и обмен ключами

• RSA — наиболее распространённый алгоритм для шифрования предварительного главного секрета. Уязвим к атаке Bleichenbacher (1998 год) и не обеспечивает совершенной прямой секретности (PFS).
• Diffie-Hellman (DH) — протокол обмена ключами, обеспечивающий PFS. Используется в вариантах с фиксированными параметрами (DHE) или на эллиптических кривых (ECDHE).
• ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) — предпочтительный вариант, так как обеспечивает PFS и высокую производительность при меньших размерах ключей.

Хеширование и HMAC

Для проверки целостности сообщений в TLS 1.2 используется HMAC (Hash-based Message Authentication Code) на основе хеш-функций:

• SHA-1 — устаревшая, с 160-битным хешем, не рекомендуется из-за коллизионных атак.
• SHA-256 — 256-битный хеш, стандарт для большинства современных наборов шифров.
• SHA-384 — 384-битный хеш, используется в наборах с AES-256-GCM.

Безопасность

Известные уязвимости

Несмотря на значительные улучшения по сравнению с TLS 1.1, TLS 1.2 имеет ряд уязвимостей, которые были выявлены после его внедрения:

• POODLE (2014 год) — атака на SSL 3.0, но также затрагивающая TLS 1.2 при использовании CBC-режима с блочными шифрами. Устранена путём отключения CBC и использования GCM.
• BEAST (2011 год) — атака на CBC-режим в TLS 1.0, но частично применима к TLS 1.2 при неправильной конфигурации.
• Lucky13 (2013 год) — атака на CBC-режим, основанная на времени обработки.
• ROBOT (2017 год) — атака на RSA-шифрование в TLS 1.2, позволяющая расшифровать предварительный главный секрет.
• Downgrade Attack — атакующий может попытаться принудительно понизить версию протокола до TLS 1.1 или 1.0, если сервер поддерживает старые версии. Для защиты в TLS 1.2 введён механизм SCSV (Signaling Cipher Suite Value).
• CRIME и BREACH (2012-2013 годы) — атаки на сжатие данных, которые могут раскрыть секретные данные. В TLS 1.2 рекомендуется отключать сжатие на уровне TLS и HTTP.

Рекомендации по безопасной настройке

Для обеспечения безопасности при использовании TLS 1.2 рекомендуется:

• Отключать поддержку TLS 1.0 и 1.1.
• Использовать только наборы шифров с PFS (ECDHE или DHE).
• Использовать только современные алгоритмы шифрования (AES-GCM, ChaCha20-Poly1305).
• Отключать сжатие на уровне TLS.
• Использовать сертификаты с длиной ключа RSA не менее 2048 бит или ECDSA с кривой P-256.
• Регулярно обновлять библиотеки TLS (например, OpenSSL, BoringSSL).

Применение

Веб-серверы и браузеры

TLS 1.2 является основным протоколом для HTTPS-соединений. Все современные браузеры (Google Chrome, Mozilla Firefox, Apple Safari, Яндекс.Браузер) поддерживают TLS 1.2. По состоянию на 2024 год, по данным SSL Labs, более 95% сайтов в интернете поддерживают TLS 1.2.

Электронная почта

TLS 1.2 используется для защиты передачи почтовых сообщений по протоколам SMTP, IMAP и POP3, а также для шифрования соединений между почтовыми серверами (MTA-STS).

VPN и другие протоколы

Некоторые VPN-решения (например, OpenVPN) могут использовать TLS 1.2 для управления ключами и аутентификации. Также TLS 1.2 применяется в протоколах WebSocket, FTP (FTPS), SIP (SIPS) и других.

Сравнение с TLS 1.3

Интересные факты

• Название «TLS» происходит от «Transport Layer Security», что подчёркивает его работу на транспортном уровне.
• TLS 1.2 стал первым протоколом в семействе TLS, который явно указал на необходимость использования HMAC для проверки целостности, а не простого хеширования.
• В 2015 году IETF опубликовала RFC 7525, который рекомендовал использовать только TLS 1.2 и выше, а также конкретные наборы шифров.
• В России использование TLS 1.2 регулируется ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012, но для государственных информационных систем часто применяются отечественные криптографические стандарты (ГОСТ 28147-89, ГОСТ Р 34.10-2012), которые могут быть реализованы в TLS 1.2 через расширения.

Источники

• RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 (2008)
• RFC 7525: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) (2015)
• RFC 7465: Prohibiting RC4 Cipher Suites (2015)
• RFC 7905: ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS) (2016)
• NIST Special Publication 800-52 Rev. 2: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations (2019)
• «SSL and TLS: Theory and Practice» by Rolf Oppliger (2016)
• Документация OpenSSL: https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_cipher_list.html