TLS 1.2 или TLS 1.3: что изменилось и что настроить

TLS 1.2 или TLS 1.3 — это уже не выбор между равными. TLS 1.2 (RFC 5246, 2008) безопасен, если ограничить его обменом ключами ECDHE и наборами шифров AEAD; TLS 1.3 (RFC 8446 в 2018 году, пересмотрен как RFC 9846 в июле 2026 года) делает такую конфигурацию единственно возможной, шифрует больше сообщений рукопожатия и остаётся единственной версией, в которой есть постквантовый гибридный обмен ключами и Encrypted Client Hello.

Коротко о главном

Рукопожатие

TLS 1.2 сначала договаривается о параметрах и только потом обменивается ключами: клиент перечисляет наборы шифров, сервер выбирает один из них и отправляет свой сертификат и параметры обмена ключами, клиент отправляет свой key share, и обе стороны завершают рукопожатие. Прежде чем пойдут данные приложения, проходят два цикла приёма-передачи, а сертификат передаётся в открытом виде. В наборах со статическим RSA клиент шифрует premaster secret на ключе из сертификата сервера, поэтому любой, кто позже получит этот ключ, сможет расшифровать каждый записанный сеанс.

TLS 1.3 действует на опережение: клиент уже в первом сообщении отправляет key share для предпочтительных групп, сервер отвечает своим key share и сразу же зашифрованными расширениями, сертификатом, CertificateVerify и Finished, и клиент может отправлять данные уже через один цикл приёма-передачи. Возобновлённые сеансы могут даже нести ранние данные 0-RTT, но ценой потери защиты от повторного воспроизведения для этих данных.

Скрипт ниже (OpenSSL 3.6.5, публичный сервер, 20 октября 2026 года) показывает, что получается на практике, когда один и тот же клиент принудительно выбирает каждую из версий.

#!/bin/sh
host=${1:-cloudflare.com}
for version in -tls1_2 -tls1_3; do
  echo "== $version"
  echo | openssl s_client -connect "$host:443" -servername "$host" "$version" -brief 2>&1 \
    | grep -E "Protocol version|Ciphersuite|Peer Temp Key|Negotiated TLS1.3 group"
done

== -tls1_2
Protocol version: TLSv1.2
Ciphersuite: ECDHE-ECDSA-CHACHA20-POLY1305
Peer Temp Key: X25519, 253 bits
== -tls1_3
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Negotiated TLS1.3 group: X25519MLKEM768

Соединение TLS 1.2 здесь безопасно, потому что сервер разрешает только ECDHE с AEAD, но оно ограничено классическим X25519; соединение TLS 1.3 согласует постквантовый гибрид.

Что удалено в TLS 1.3 и почему

Почти каждая известная атака на TLS 2010-х годов использовала возможность эпохи TLS 1.2, которую TLS 1.3 удалил:

• Режим CBC со схемой «сначала MAC, затем шифрование» (BEAST, Lucky Thirteen, POODLE): остались только шифры AEAD.
• RC4 (статистические смещения) и 3DES (SWEET32): удалены.
• Передача ключа через RSA (атаки Блейхенбахера с оракулом дополнения, ROBOT; нет прямой секретности): удалена.
• Группы экспортного уровня и произвольные группы над конечными полями (FREAK, Logjam): остались только именованные группы.
• Повторное согласование и сжатие (атака тройного рукопожатия, CRIME): удалены.
• Подписи только над частью транскрипта (в TLS 1.2 подпись в ServerKeyExchange охватывает только параметры): CertificateVerify подписывает весь транскрипт.
• SHA-1 и MD5 в подписях: удалены.

RFC 9846 также ужесточает требования к реализациям TLS 1.2, а RFC 9325 описывает безопасное подмножество TLS 1.2: ECDHE или DHE с AEAD, extended master secret (RFC 7627) и безопасное повторное согласование.

Возможности, которые есть только в TLS 1.3

• Гибридный постквантовый обмен ключами (X25519MLKEM768, RFC 10024): основные браузеры согласуют его по умолчанию с конца 2024 года, OpenSSL — с версии 3.5.
• Encrypted Client Hello (RFC 9849): вместе с DNS-записями HTTPS скрывает имя сервера от наблюдателей в сети.
• Сжатие сертификатов (RFC 8879) и делегированные учётные данные (RFC 9345).
• QUIC: встраивает рукопожатие TLS 1.3 и служит транспортом для HTTP/3.

Требования регуляторов и политики

• Федеральные системы США: NIST SP 800-52 Rev. 2 требует, чтобы государственные TLS-серверы поддерживали TLS 1.3 к 1 января 2024 года, и разрешает TLS 1.2 с одобренными наборами шифров.
• Среды обработки платёжных карт: PCI DSS запрещает SSL и ранний TLS (1.0) с 30 июня 2018 года; допустимы и TLS 1.2, и TLS 1.3.
• IETF: RFC 8996 в 2021 году объявил TLS 1.0 и 1.1 устаревшими; браузеры удалили их в 2020 году.
• Планы перехода на постквантовую криптографию: NIST IR 8547 (проект) и CNSA 2.0 исходят из гибридного или постквантового установления ключей, а оно доступно только в TLS 1.3.

Что когда выбирать

• Публичные сайты и API: предпочтительно TLS 1.3, TLS 1.2 с безопасным подмножеством — как запасной вариант.
• Внутренние сервисы, сервисные сетки (service mesh), mTLS: только TLS 1.3.
• Устаревшие клиенты (старые версии Android, встраиваемые устройства, старые версии Java и Windows): TLS 1.2 с ECDHE и AEAD; запланируйте вывод таких клиентов из эксплуатации.
• Промежуточные устройства, которые инспектируют трафик: рассчитывайте на то, что их придётся обновить для TLS 1.3, ECH и больших постквантовых ClientHello, а не сдерживать из-за них развитие серверов.
• Всё, чему нужна постквантовая конфиденциальность: TLS 1.3 с гибридной группой.

Заметки о миграции

1. Обновите библиотеку TLS: OpenSSL 1.1.1 или новее для TLS 1.3, 3.5 или новее для постквантовых групп по умолчанию; актуальные BoringSSL и Go, Java 11 или новее, Windows Server 2022 или новее.
2. Включите TLS 1.3 рядом с 1.2, затем сократите 1.2 до наборов с ECDHE и AEAD; в nginx — ssl_protocols TLSv1.2 TLSv1.3; с коротким списком ssl_ciphers, поскольку наборы TLS 1.3 настраиваются отдельно.
3. Проверьте сертификаты и ключи: RSA-сертификаты работают с TLS 1.3, потому что подписи рукопожатия используют PSS с теми же ключами; сертификаты ECDSA работают без изменений.
4. Решите, нужен ли 0-RTT: оставьте его выключенным, если только приложение не умеет безопасно обрабатывать повторное воспроизведение ранних запросов.
5. Измерьте оставшийся трафик TLS 1.2 и назначьте дату его отключения там, где он упадёт до нуля. Генератор конфигурации TLS создаёт настройки для распространённых серверов, а массовая проверка доменов показывает, какие версии принимают ваши хосты.

Источники

• RFC 9846, TLS 1.3 (§ 1.3 — отличия от TLS 1.2, § 1.4 — изменения, затрагивающие TLS 1.2)
• RFC 5246, TLS 1.2
• RFC 9325, рекомендации по безопасному использованию TLS и DTLS
• RFC 8996, вывод TLS 1.0 и TLS 1.1 из употребления
• RFC 10024, гибридное согласование ключей на основе ML-KEM для TLS 1.3
• RFC 9849, TLS Encrypted Client Hello
• NIST SP 800-52 Rev. 2
• PCI SSC: переход с SSL и раннего TLS