TLS (Transport Layer Security).

TLS располагается между прикладным протоколом (HTTP, SMTP, IMAP, gRPC и др.) и транспортом (обычно TCP, в QUIC — UDP), превращая открытый двунаправленный поток в аутентифицированный шифрованный канал. В рукопожатии сервер (и при желании клиент) аутентифицируется по X.509-сертификатам, согласуется крипто-набор и выводятся сеансовые ключи — как правило, через Diffie–Hellman на эллиптических кривых (ECDHE) ради forward secrecy: даже будущая компрометация ключа не позволит расшифровать перехваченный ранее трафик.

Версии. Активно используются TLS 1.2 (RFC 5246, 2008) и TLS 1.3 (RFC 8446, 2018). TLS 1.3 убирает устаревшие алгоритмы (RC4, режим CBC, статический обмен RSA), сокращает рукопожатие до одного round-trip и добавляет опциональное 0-RTT-возобновление. SSL 2.0/3.0 и TLS 1.0/1.1 официально признаны устаревшими в RFC 8996 (2021).

Реальные слабости. Безопасность TLS чаще рушится в реализации, а не в дизайне. Heartbleed (CVE-2014-0160) позволял читать память сервера OpenSSL, включая закрытые ключи, через некорректный heartbeat. POODLE (CVE-2014-3566) использовал CBC-паддинг SSL 3.0; BEAST (CVE-2011-3389) и Lucky Thirteen (CVE-2013-0169) били по CBC в TLS 1.0. Это ускорило переход на TLS 1.2+ с AEAD-алгоритмами вроде AES-GCM и ChaCha20-Poly1305.

Защита. Отключить устаревшие версии и наборы шифров, включить OCSP stapling и Certificate Transparency, принудительно применять HSTS, ротировать ключи и внедрять mTLS для межсервисного взаимодействия и zero-trust моделей.

flowchart TD
  A[Client Hello: версии + список шифров + key share] --> B[Сервер]
  B --> C[Server Hello: выбранный набор + key share]
  C --> D[Сервер отправляет цепочку сертификатов X.509]
  D --> E[Клиент проверяет цепочку по доверенному CA]
  E --> F[Обмен ECDHE выводит общий секрет]
  F --> G[Обе стороны выводят сеансовые ключи]
  G --> H[Шифрованные данные приложения: AES-GCM / ChaCha20-Poly1305]