Этап 5 — TLS 1.3: handshake до последнего байта

«Замочек в браузере» — это полстраницы криптографии в одном маленьком handshake. Сейчас разберём TLS 1.3 на молекулы: ClientHello, ServerHello, ECDHE, цепочка сертификатов, OCSP, 0-RTT, session resumption, ECH.

1. Зачем TLS 1.3, а не 1.2

TLS 1.3 — стандарт с 2018. По сравнению с 1.2 — это революция:

В 2026: TLS 1.3 обязательно, 1.2 — только legacy-клиенты, 1.0/1.1 — давно отключены везде.

2. Handshake — поле за полем

TLS 1.3 handshake состоит из 4 групп сообщений. Разберём каждое в деталях.

ClientHello — самое большое сообщение

Это «вступление» клиента. Хотя выглядит как один пакет, внутри — много extension'ов:

ClientHello {
  legacy_version: 0x0303,                 # TLS 1.2 (для совместимости с middleboxes)
  random: 32 байта случайных,
  legacy_session_id: 32 байта (или 0),
  cipher_suites: [
    TLS_AES_128_GCM_SHA256,
    TLS_AES_256_GCM_SHA384,
    TLS_CHACHA20_POLY1305_SHA256,
    ...                                    # список того, что клиент поддерживает
  ],
  legacy_compression_methods: [0x00],     # no compression

  extensions: [
    supported_versions: [TLS 1.3, TLS 1.2],
    supported_groups: [x25519, secp256r1, secp384r1, ...],
    signature_algorithms: [ecdsa_secp256r1_sha256, rsa_pss_rsae_sha256, ...],
    key_share: [
      {group: x25519, key: 32 байта публичного ECDHE},
      ...
    ],
    server_name: [host="app.example.com"],   # ★ SNI — критично
    application_layer_protocol_negotiation: ["h2", "http/1.1"],   # ★ ALPN
    psk_key_exchange_modes: [psk_dhe_ke],    # для resumption
    pre_shared_key: ...,                     # если это resumption
    early_data: ...,                         # если 0-RTT
    encrypted_client_hello: ...,             # ECH (опц.)
  ]
}

Каждое поле важно. Разберём ключевые.

3. SNI — Server Name Indication

На одном IP может быть хостингов десятки сайтов. Когда клиент устанавливает TLS, сервер должен знать, для какого хоста отдать сертификат. SNI — это extension в ClientHello, где клиент указывает server_name.

Проблема: SNI идёт в открытом виде (это до того, как ключ согласован). Провайдер видит, к какому сайту ты обращаешься, даже не видя содержимого.

Решение: ECH (Encrypted Client Hello) — RFC 9180. Клиент берёт публичный ключ из HTTPS-DNS-записи, шифрует SNI плюс другие фингерпринт-extensions, и шлёт как «outer ClientHello» с фейковым именем. Сервер расшифровывает.

ECH развёрнут в Cloudflare, Firefox/Chrome поддерживают. Это серьёзный шаг для приватности.

4. ALPN — Application Layer Protocol Negotiation

В TLS 1.2 после handshake клиент мог только начать слать HTTP/1.1. Чтобы согласовать HTTP/2 или HTTP/3, нужен extension ALPN.

Клиент шлёт список — «я могу h2, http/1.1». Сервер в ServerHello выбирает — «давай h2». Дальше пакеты — это HTTP/2 frames.

Без ALPN — нет HTTP/2. Это тоже основа быстрого веба сейчас.

5. ECDHE — обмен ключами по математике

Это сердце TLS. Обе стороны должны договориться о симметричном ключе, не передавая его в клире. Diffie-Hellman решает эту задачу с 1976 года.

Идея (упрощённо)

1. Клиент берёт случайное число a (приватное), вычисляет A = g^a mod p. Отправляет A.
2. Сервер берёт случайное b, вычисляет B = g^b mod p. Отправляет B.
3. Клиент вычисляет S = B^a mod p. Сервер вычисляет S = A^b mod p. Это одно и то же число — общий секрет.
4. Атакующий видит g, p, A, B — но вычислить a или b из A или B вычислительно сложно (discrete log problem).

ECDHE — то же самое, но на эллиптических кривых (Curve25519, P-256). Безопаснее при том же размере ключа, быстрее.

«E» в конце — Ephemeral, то есть ключи генерируются заново при каждом handshake. Это обеспечивает Forward Secrecy: даже если завтра украдут приватный ключ сервера, прошлые сессии расшифровать нельзя — там были другие эфемерные ключи.

6. Сертификат и цепочка

Сервер шлёт цепочку сертификатов (Certificate сообщение, зашифровано в TLS 1.3). Клиент проверяет:

Что значит «доверенный root»

В твоём браузере / ОС вшит trust store — список ~150-200 root-сертификатов. Если цепочка от твоего сертификата приходит к одному из них — браузер доверяет. Если нет — большая красная страница.

Каждый root CA проходит аудит, делает Key Signing Ceremony, и должен выпускать сертификаты только подтверждённым владельцам доменов.

SAN, wildcards и multi-domain

# Wildcard покрывает один уровень
*.example.com  →  www.example.com, api.example.com  ✓
              →  app.staging.example.com  ✗

# Multi-SAN — много имён в одном сертификате
SAN: example.com, www.example.com, api.example.com, *.staging.example.com

7. OCSP — отзыв сертификатов

Что, если сертификат скомпрометирован и его нужно отозвать до истечения срока? Есть два механизма:

OCSP stapling

Решение — OCSP stapling: сервер сам периодически запрашивает свой OCSP-статус и «прикладывает» его к сертификату в handshake. Клиент получает свежий статус без отдельного запроса.

Это включается в Nginx / Caddy одной строкой:

ssl_stapling on;
ssl_stapling_verify on;

OCSP Must-Staple

В сертификате может быть расширение OCSP Must-Staple — это говорит браузеру: «без OCSP-staple не доверяй мне». Защита от ситуации «OCSP сервер атакован, и через 7 дней при тишине считается ok».

8. Session resumption — экономия RTT

Сделал handshake, открыл сайт, закрыл. Через минуту вернулся. Можно ли не делать handshake заново?

TLS 1.3 поддерживает два режима:

Session Tickets

Сервер в конце handshake шлёт session ticket — зашифрованный своим ключом «снимок» состояния. Клиент сохраняет. При следующем подключении вкладывает ticket в ClientHello. Сервер расшифровывает и понимает: «о, это та же сессия». Не нужно делать новый ECDHE.

PSK (Pre-Shared Key)

Аналогично, но «ключ» хранит и сервер, и клиент. Используется в IoT и контролируемых сценариях.

Resumption экономит RTT — handshake становится «0.5-RTT» вместо 1-RTT.

9. 0-RTT — отправить данные сразу с ClientHello

Самая агрессивная оптимизация. При resumption клиент может вложить данные в первое же сообщение — раньше, чем handshake завершён.

ClientHello {
  pre_shared_key: <ticket>,
  early_data: enabled,
  ...
}
+ Application Data (HTTP-запрос!)  ← данные едут СРАЗУ

Сервер расшифровывает и обрабатывает запрос. Ответ возвращается за 1 RTT — фактически 0 RTT для данных от клиента.

10. Шифры в TLS 1.3 — все пять

В TLS 1.2 было 300+ cipher suites, многие небезопасные. В TLS 1.3 — пять, все безопасные AEAD-шифры:

AEAD = Authenticated Encryption with Associated Data. Шифрование + integrity check в одном алгоритме. Никакого MAC-then-encrypt или encrypt-then-MAC — это уязвимости 1.2.

11. Post-quantum — что будет завтра

Квантовые компьютеры (когда они появятся) смогут сломать ECDHE и RSA. Сегодня атакующие могут хранить зашифрованные сессии и расшифровать через 10 лет, когда квантовые компьютеры станут реальностью. Это называется «harvest now, decrypt later».

Решение — post-quantum cryptography. В 2024 NIST стандартизировал ML-KEM (Kyber). Cloudflare, Google, Apple уже разворачивают X25519MLKEM768 — гибрид классической X25519 и Kyber. Это компромисс: если Kyber сломают — X25519 защитит. Если X25519 сломают (квантовым) — Kyber защитит.

Запомни: гибриды развёрнуты в Chrome, Cloudflare с 2024. Скоро ты увидишь это и на серверах.

12. mTLS — взаимная аутентификация

Обычный TLS аутентифицирует только сервер. Клиент анонимен (или авторизуется через Bearer-токен поверх TLS).

mTLS — обе стороны предъявляют сертификаты. Сервер в CertificateRequest просит клиента: «дай свой сертификат». Клиент шлёт свой Certificate + CertVerify (подписывает hash handshake-сообщений своим приватным ключом).

Где используется:

• Service Mesh (Istio, Linkerd) — каждый микросервис имеет свой cert, идентичность = cert
• Zero Trust — отказ от «сети как периметра», идентичность — основа доступа
• API между партнёрами — банки, фин-теки, медицина
• Device authentication — IoT

13. TLS terminator и middleware

В реальности TLS терминируется не на твоём приложении — а раньше:

• CDN (Cloudflare) — на edge
• WAF — между CDN и origin
• Load balancer (ALB / Nginx) — на границе твоего VPC
• Service mesh sidecar (Envoy) — на каждом pod

То есть один запрос может пройти через 3-4 TLS-туннеля. На каждом — отдельный handshake, сертификаты, OCSP.

Это нормально. Но за этим нужно следить:

• Все сертификаты должны вовремя обновляться
• Версии TLS должны быть согласованы
• mTLS внутри кластера — желательно

14. Мини-лаба: попробуй прямо сейчас

openssl есть почти в любой системе (в Windows — в составе Git Bash). Разбери «замочек» любого сайта:

# Полный handshake вживую
openssl s_client -connect example.com:443 -servername example.com -tls1_3

# Какие TLS-версии поддерживает сервер
nmap --script ssl-enum-ciphers -p 443 example.com

# Цепочка сертификатов и сроки
echo | openssl s_client -connect example.com:443 -showcerts 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

# Только дата истечения, ничего лишнего
echo | openssl s_client -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -enddate

# OCSP — проверить статус
openssl ocsp -issuer chain.pem -cert cert.pem \
  -url http://ocsp.example.com -resp_text

# Проверить весь сайт онлайн
# https://www.ssllabs.com/ssltest/  → A+ обязательно

# Сделать локальный самоподписанный для тестов
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem \
  -days 365 -nodes -subj "/CN=localhost"

15. Что с этим делает DevOps

16. Задачи самопроверки — реши, потом раскрой ответ

17. Словарик урока

Чек-лист «понимаю это»