TLS 1.3: что меняется и как это проверить
Обновлено 2026-11-03 · 6 мин чтения
TLS 1.3 — первая за десятилетие ревизия протокола, которая убирает возможности, а не добавляет их. Именно поэтому он быстрее и его труднее настроить неправильно — и поэтому сервер, говорящий только по TLS 1.2, не может получить высшую оценку.
Что изменилось по сравнению с TLS 1.2
TLS 1.3 сокращает рукопожатие с двух круговых обменов до одного, а при возобновлении — до нуля. Он убирает статический обмен ключами RSA и Diffie-Hellman, поэтому прямая секретность становится обязательной, а не опциональной. Он полностью отказывается от наборов в режиме CBC, RC4, SHA-1 и сжатия и шифрует больше частей рукопожатия — включая сертификат — чтобы посредники узнавали меньше.
Практическое следствие: почти все исторические слабости, требовавшие аккуратной настройки, теперь невозможны. В TLS 1.3 нельзя случайно согласовать слабый набор, потому что протокол определяет только AEAD-наборы с современными хешами.
Почему это важно для оценки
CertH требует TLS 1.3 для A+ независимо от всего остального. Сайт с идеальным сертификатом, стойкими шифрами и HSTS без него упирается в 95 и A. Эта одна строка — самая частая причина, по которой хорошо обслуживаемый сайт застревает на A.
Вторая причина — само рукопожатие. На мобильном соединении с высокой задержкой сэкономленный круговой обмен это десятки-сотни миллисекунд на каждом новом соединении: прямой и измеримый эффект на воспринимаемую скорость.
Как включить
В nginx поддержка TLS 1.3 зависит от версии OpenSSL, с которой собран бинарник. Нужен OpenSSL 1.1.1 или новее; проверьте через nginx -V строку built with OpenSSL до любых правок.
В Apache достаточно SSLProtocol, если httpd слинкован с современным OpenSSL. В Cloudflare TLS 1.3 — переключатель уровня зоны в SSL/TLS → Edge Certificates, и с 2021 года он включён по умолчанию для большинства зон.
# nginx: does this binary even support TLS 1.3?
nginx -V 2>&1 | tr ' ' '\n' | grep -i openssl
# negotiate TLS 1.3 explicitly and print the protocol
openssl s_client -connect example.com:443 -tls1_3 -servername example.com </dev/null 2>/dev/null | grep -E "Protocol|Cipher"Подводные камни, о которых не говорят
Возобновление 0-RTT быстрое, но воспроизводимое: злоумышленник, перехвативший первый полёт, может отправить его повторно. Никогда не разрешайте 0-RTT на эндпоинтах, меняющих состояние при первом запросе, — например, там, где что-то записывается.
Часть корпоративных промежуточных устройств до сих пор ломается на TLS 1.3. Держать TLS 1.2 включённым рядом — стандартный компромисс: совместимость сохраняется, а требование A+ всё равно выполнено, потому что оценщик ищет наличие TLS 1.3, а не отключение TLS 1.2.
Наконец, CDN или балансировщик, завершающий TLS, полностью скрывает источник. Менять источник, не меняя edge, — значит не менять ничего, что может увидеть внешний сканер.
FAQ
Стоит ли отключать TLS 1.2 после включения TLS 1.3?
Нет. TLS 1.2 сохраняет совместимость со старыми клиентами и промежуточными устройствами и не стоит баллов. Отключение лишь убирает варианты отката.
Меняет ли TLS 1.3 требования к сертификату?
Он делает часть устаревших алгоритмов непригодными. Сертификаты с ключом RSA по-прежнему подходят, но цепочка должна использовать алгоритмы подписи, разрешённые протоколом: подписи SHA-1, например, в TLS 1.3 непригодны.