TLS 1.3: handshake, cipher suites и практические проверки

⚙️ Теория

🔐 Что изменилось в TLS 1.3

RFC 8446 упростил и усилил протокол:

handshake сокращен до 1-RTT для нового соединения;
используются только современные наборы шифров (AEAD + HKDF key schedule);
убраны устаревшие/слабые механизмы прошлых версий;
добавлен режим 0-RTT для возобновления сессии (с отдельными оговорками по безопасности).

Отдельно: RFC 8996 объявляет TLS 1.0 и TLS 1.1 устаревшими.

🔄 Handshake TLS 1.3 (упрощенно)

Полный handshake:

Клиент отправляет ClientHello (supported_versions, key_share, signature_algorithms и др.).
Сервер отвечает ServerHello, после чего большая часть сообщений шифруется.
Сервер отправляет EncryptedExtensions, Certificate, CertificateVerify, Finished.
Клиент отправляет Finished.
Канал готов к передаче прикладных данных.

Ключевая практическая разница с TLS 1.2: меньше round-trips и меньше исторического крипто-наследия.

⚠️ 0-RTT и риск replay

TLS 1.3 поддерживает early data (0-RTT) при resumption через PSK.
Цена ускорения: early data может быть replay-атачена, поэтому:

нельзя использовать 0-RTT для неидемпотентных операций;
сервер должен применять anti-replay стратегию и ограничивать сценарии early data.

🛡️ Downgrade-защита

TLS 1.3 включает механизмы downgrade protection в согласовании версии (RFC 8446).
На практике это снижает риск принудительного отката клиента/сервера на более слабую версию протокола.

❓ Что нужно уметь объяснить

Почему "включить TLS 1.3" недостаточно?

Потому что безопасность определяется не только версией протокола, но и политикой:

какие версии/алгоритмы разрешены;
как настроены сертификаты и ротация;
разрешен ли 0-RTT и для каких эндпоинтов.

Почему 0-RTT нельзя включать без условий?

Из-за replay-рисков.
Если endpoint изменяет состояние (например, платеж, создание ресурса), 0-RTT может нарушить безопасность бизнес-операции.

Что важнее в production: "максимальная совместимость" или "крипто-строгость"?

Это компромисс. Но в 2026 году в большинстве production-сценариев стоит делать ставку на TLS 1.2/1.3, а TLS 1.0/1.1 держать выключенными (RFC 8996).

🧪 Практика

1. Проверка negotiated version и ciphersuite

openssl s_client -connect example.com:443 -tls1_3 -servername example.com

Проверяем:

действительно ли согласован TLSv1.3;
какой Cipher выбран;
корректность сертификатной цепочки.

2. Проверка отказа от устаревших версий

openssl s_client -connect example.com:443 -tls1
openssl s_client -connect example.com:443 -tls1_1

Ожидаемое поведение для современного контура: отказ в handshake для TLS 1.0/1.1.

3. Проверка 0-RTT политики

Если 0-RTT включен:

разрешайте его только для безопасных идемпотентных операций;
отключайте для state-changing endpoint'ов;
фиксируйте в метриках количество early-data запросов и отклонений.

4. Операционные guardrails

обновляйте TLS-библиотеки и OpenSSL/NSS/BoringSSL на поддерживаемые ветки;
контролируйте срок действия сертификатов и автоматизацию ротации;
проверяйте конфиг после каждого изменения reverse proxy/ingress.

🧾 Вывод

TLS 1.3 дает более быстрый и более строгий криптографический профиль по сравнению с TLS 1.2, но итоговая безопасность зависит от operational policy.
Критичный минимум:

отключить TLS 1.0/1.1,
контролировать cipher/config drift,
осторожно обращаться с 0-RTT,
регулярно верифицировать конфигурацию инструментально.