За каждым HTTPS-соединением скрыт протокол, который умещается в десятки миллисекунд. Клиент и сервер договариваются о криптографических параметрах, проверяют идентичность и выводят ключи — всё это до первого байта HTTP-ответа. Большинство разработчиков описывают этот процесс одной фразой: «есть сертификат — значит шифрование». Это описание технически неверно. И предсказуемо создаёт проблемы в production.
Оглавление
SSL умер, да здравствует SSL — почему все до сих пор говорят «SSL-сертификат»
Forward secrecy: почему украденный сертификат — не катастрофа
Статья разбирает TLS 1.3 по шагам: как устроен handshake, почему сертификат не шифрует трафик, как ECDHE позволяет двум сторонам получить общий секрет без его передачи и где заканчивается защита TLS — и начинается уязвимость приложения.
Актуальный контекст: в июле 2026 года IETF опубликовал RFC 9846 — обновлённую редакцию спецификации TLS 1.3, заменившую RFC 8446. Одновременно RFC 9852 закрепил: новые протоколы, использующие TLS, обязаны требовать TLS 1.3. TLS 1.2 официально переведён в режим feature freeze (RFC 9851). Хороший момент разобраться, что именно стоит за этим решением.
SSL умер, да здравствует SSL — почему все до сих пор говорят «SSL-сертификат»
SSL (Secure Sockets Layer) разрабатывался Netscape в середине 1990-х. SSL 2.0 вышел в 1995 году, SSL 3.0 — в 1996-м. Уже в 1999 году TLS 1.0 заменил SSL как стандарт. SSLv3 уязвим к атаке POODLE, SSLv2 — к DROWN. Обе версии deprecated и давно отключены в нормальной инфраструктуре.
Слово «SSL» осталось как бытовое название: продавцы сертификатов закрепили его в маркетинге — и понятие «SSL-сертификат» прижилось. В технической документации, вакансиях и разговорах правильно использовать TLS. Современный протокол — это TLS 1.3 согласно RFC 9846.
Три задачи TLS
TLS — не шифр. Это протокол оркестрации криптографии, который одновременно решает три задачи:
Authentication — клиент проверяет, с кем говорит, до того как передаёт что-либо важное;
Key agreement — клиент и сервер получают общий секрет, не передавая его по сети;
Confidentiality + Integrity — после handshake весь трафик защищается симметричным AEAD-шифрованием.
Сертификат отвечает только за первую задачу: аутентификацию. Ключи сессии генерируются отдельно — через ECDHE и HKDF. Именно поэтому фраза «сертификат — это ключ шифрования сайта» фундаментально неверна.
ClientHello: что клиент говорит первым
TLS handshake начинается с сообщения ClientHello. Клиент объявляет всё, что умеет:
ClientHello
├── supported_versions (TLS 1.3, TLS 1.2)
├── cipher_suites (TLS_AES_256_GCM_SHA384, ...)
├── SNI (имя хоста)
├── ALPN (h2, http/1.1)
├── supported_groups (x25519, secp256r1)
├── key_share (ECDHE публичный ключ клиента)
├── signature_algorithms
└── PSK / session resumption (если применимо)
Ключевое отличие TLS 1.3 от предыдущих версий: клиент не ждёт, пока сервер выберет группу. Он сразу отправляет key_share для наиболее вероятных групп. Сервер выбирает подходящую и отвечает своим key_share — отдельный round-trip на согласование параметров не нужен. После ServerHello большая часть handshake уже идёт в зашифрованном виде. IETF описывает стадии как Key Exchange → Server Parameters → Authentication.
ECDHE: общий секрет без передачи секрета
Diffie-Hellman в варианте на эллиптических кривых (ECDHE) решает задачу, которая выглядит парадоксально: два участника получают одинаковый секрет, не передавая его по сети.
На примере X25519:
Клиент: Сервер:
private C private S
public C_pub public S_pub
по сети: C_pub, S_pub
shared_secret = shared_secret =
ECDHE(C, S_pub) ECDHE(S, C_pub)
Обе стороны вычисляют одинаковый shared_secret, зная только свой приватный ключ и публичный ключ собеседника. Злоумышленник видит C_pub и S_pub, но восстановить shared_secret без решения задачи дискретного логарифма на эллиптической кривой практически невозможно.
«Ephemeral» означает: эти ключи генерируются заново для каждой сессии. Долгосрочные ключи сертификата не используются для шифрования трафика — только для аутентификации. Это фундамент forward secrecy.
HKDF и конвейер ключей
TLS 1.3 не использует shared_secret напрямую как ключ шифрования. Секреты прогоняются через HKDF key schedule — функцию извлечения и расширения ключей на основе HMAC:
ECDHE shared_secret
|
v
HKDF-Extract
|
+---- Handshake Traffic Secret
| ├── client_handshake_traffic_secret
| └── server_handshake_traffic_secret
|
+---- Master Secret
├── client_application_traffic_secret
├── server_application_traffic_secret
├── exporter_master_secret
└── resumption_master_secret
Из одного shared_secret выводится целый набор независимых секретов: отдельно для handshake, отдельно для application data, отдельно для resumption. Компрометация одного не раскрывает остальных автоматически. TLS — не один ключ. Это конвейер производных секретов. Финальные ключи используются в AEAD-режиме: TLS 1.3 оставил только AES-128-GCM, AES-256-GCM и ChaCha20-Poly1305. Никакого CBC, никакого RC4.
Сертификат и PKI: кому доверяет клиент
После ServerHello сервер отправляет Certificate. Клиент проверяет:
Root CA (в trust store клиента)
└── Intermediate CA
└── Server certificate
├── SAN (Subject Alternative Name: domain.com)
├── Public key
├── Validity
└── Key Usage / Extended Key Usage
Цепочка доверия строится от сертификата сервера до корневого CA в trust store клиента. Если цепочка корректна, hostname совпадает с SAN и сертификат не истёк — клиент доверяет публичному ключу сервера.
Здесь важно понять: проверяется именно «этому публичному ключу можно верить, потому что CA его подписал». Сам факт наличия сертификата не защищает трафик — это только аутентификация, первая из трёх задач TLS.
CertificateVerify и Finished
Сертификат отвечает на вопрос «какому публичному ключу доверять?». Но откуда клиент знает, что сервер действительно владеет соответствующим приватным ключом?
Сообщение CertificateVerify содержит подпись, вычисленную приватным ключом сервера над хешем всего handshake-транскрипта. Клиент проверяет эту подпись публичным ключом из сертификата. Если подпись верна — сервер владеет приватным ключом.
Finished завершает аутентификацию с обеих сторон: оба участника подтверждают целостность handshake через HMAC над тем же транскриптом. После успешного Finished начинается передача application data.
Полная схема:
CLIENT SERVER
| |
|---- ClientHello -----------------------> |
| (key_share, SNI, cipher_suites) |
| |
| <--- ServerHello ----------------------- |
| (key_share, cipher suite) |
| |
| <--- EncryptedExtensions [зашифровано] |
| <--- Certificate [зашифровано] |
| <--- CertificateVerify [зашифровано] |
| <--- Finished [зашифровано] |
| |
|---- Finished ---------------------------> |
| |
|======= Application Data ================ |
TLS 1.2 vs TLS 1.3
TLS 1.2 | TLS 1.3 | |
Key exchange | RSA, DHE, ECDHE | Только ECDHE / PSK |
RSA key exchange | Был возможен | Отсутствует |
CBC cipher suites | Возможны | Отсутствуют |
AEAD | Возможен | Обязателен |
Forward secrecy | Зависит от конфигурации | Встроен |
0-RTT | Нет | Есть для resumption |
Handshake в зашифрованном виде | Частично | Большая часть |
Round trips до данных | 2-RTT | 1-RTT (0-RTT для resumption) |
RFC 9852 (июль 2026) закрепил: новые протоколы, использующие TLS, обязаны требовать TLS 1.3. RFC 9851 зафиксировал feature freeze TLS 1.2 — дальнейшие изменения ограничены security fixes. RFC 10015 deprecated RSA и finite-field DH key exchange в TLS 1.2. TLS 1.0/1.1 deprecated ещё RFC 8996. Это не рекомендации отдельных security-блогов. IETF закрепил TLS 1.3 как базовый протокол для новых разработок, а TLS 1.2 переведён в статус compatibility layer.
0-RTT: ускорение с ценой
При повторном подключении TLS 1.3 позволяет клиенту отправить application data сразу вместе с первым сообщением — это 0-RTT resumption на основе PSK. Latency снижается: сервер получает данные ещё до завершения handshake. Но есть принципиальное ограничение: 0-RTT data потенциально replayable.
Злоумышленник, захвативший 0-RTT запрос, может повторить его. Поэтому 0-RTT нельзя использовать для запросов с побочными эффектами без специальной replay-защиты:
POST /transfer-money — нельзя в 0-RTT без replay-защиты
POST /delete-account — нельзя в 0-RTT без replay-защиты
GET /public-content — допустимо
RFC 9846 описывает этот компромисс подробно. Решение — либо исключить 0-RTT для изменяющих операций, либо реализовать server-side replay detection.
Что TLS не защищает
Распространённое заблуждение: «HTTPS включён — значит защищено». Это верно только для транспортного уровня. С работающим TLS 1.3 и корректным сертификатом сервер остаётся уязвим к:
SQL injection;
XSS;
SSRF;
краже session token;
broken authorization;
компрометации endpoint.
OWASP Transport Layer Security Cheat Sheet прямо указывает: TLS обеспечивает confidentiality, integrity и server authentication, но не заменяет безопасность приложения.
Второй нюанс — metadata. TLS скрывает application data, но не всё. В зависимости от конфигурации наблюдатель может видеть IP-адреса, timing, размеры пакетов, SNI (в классическом сценарии без ECH) и TLS fingerprint клиента. Encrypted Client Hello (ECH) — современное расширение, которое постепенно закрывает этот зазор, шифруя часть ClientHello.
Понять, где заканчивается защита TLS и начинается уязвимость приложения, важнее, чем знать алгоритм HKDF наизусть. Этот уровень (cookie, CSP, XSS, SQL injection, WAF) довольно подробно разбирается на курсе HTML Academy «Протоколы и сети: веб-безопасность».
Программа ориентирована на web-разработчика: около месяца самостоятельного обучения, стоимость — около 22 410 ₽ согласно каталогу Хабр Курсов (цены динамические, стоит уточнять). Это не курс по PKI или TLS-инфраструктуре, но для понимания application security layer он закрывает именно тот пробел, который TLS не закрывает сам.
Подробности программы — в каталоге Хабр Курсов
TLS в production-архитектуре
Понять handshake в изоляции недостаточно. В реальной инфраструктуре TLS существует в контексте:
Internet
|
HTTPS
v
[CDN / Load Balancer] ← TLS termination здесь
|
HTTP или HTTPS
v
[Nginx / Reverse Proxy]
|
HTTP или HTTPS
v
[Backend Service]
|
HTTP
v
[DB / Internal Services]
TLS termination означает, что шифрование завершается на LB или reverse proxy. Трафик внутри кластера идёт без TLS — это осознанный компромисс между производительностью и защитой внутреннего трафика. Если модель угроз требует защиты и внутри сети, нужен mTLS до каждого сервиса.
mTLS (mutual TLS) — аутентификация обеих сторон, не только сервера. Используется в service mesh (Istio, Linkerd), микросервисных архитектурах и везде, где важно, что клиент — тоже известный сервис, а не просто «кто-то с корректным запросом».
Certificate lifecycle создаёт больше production-проблем, чем понимание AES-GCM. Ротация сертификатов, PKI-контур, управление trust stores, мониторинг expiration и автоматизация выпуска — именно здесь реально ломается инфраструктура.
Практика: расследуем handshake_failure
Сценарий: после замены сертификата часть клиентов получает handshake_failure, остальные работают нормально.
Шаг 1. Проверить handshake напрямую:
openssl s_client \
-connect example.com:443 \
-servername example.com \
-tls1_3 \
-showcerts
Смотреть: negotiated version, cipher suite, certificate chain, SAN, issuer, validity, verification result.
Шаг 2. Попробовать curl с явной версией:
curl -vI --tlsv1.3 https://example.com/
Шаг 3. Если проблема воспроизводится только у части клиентов — сравнить ClientHello проблемных и нормальных:
TLS version ← поддерживает ли клиент TLS 1.3?
cipher suites ← есть ли общие с сервером?
signature algorithms ← совместим ли алгоритм из сертификата?
supported groups ← есть ли общие ECDHE группы?
SNI ← корректно ли передаётся hostname?
Шаг 4. Packet-level анализ:
tcpdump -i eth0 -s 0 -w tls.pcap host <client-ip>
Открыть capture в Wireshark. Для расшифровки application data нужен SSLKEYLOGFILE — переменная окружения, которую поддерживают браузеры и многие HTTP-клиенты. Wireshark документирует явно: для TLS 1.3 и сессий с ECDHE расшифровка работает через key log file, а не через RSA private key сервера.
Карта локализации:
Где падает handshake?
|
+-- До ServerHello → negotiation mismatch (версии, cipher suites)
+-- На Certificate → PKI / chain / hostname / trust store
+-- На CertificateVerify → signature / key mismatch
+-- После Finished → проблема уже не в TLS, а в HTTP / application
Умение читать pcap и локализовать TLS failure — это навык, который отделяет «знаю TLS по схемам» от «могу разобрать реальную аварию». Уровень tcpdump, Wireshark, анализа TCP-сессий, retransmits и MITM-сценариев покрывает курс IBS «Перехват и анализ трафика: от теории к практике с Tcpdump и Wireshark». Программа посвящена сетевому анализу в целом: OSI, TCP/UDP, HTTP, DNS, Wi-Fi, pcap — TLS здесь часть общего packet-analysis skillset, а не единственная тема. Формат: онлайн, 1 неделя, 65 900 ₽, сертификат.
Подробности — в каталоге Хабр Курсов
Forward secrecy: почему украденный сертификат — не катастрофа
Допустим, злоумышленник сегодня получил приватный ключ сертификата сервера. При корректно настроенном TLS 1.3 это не означает автоматической расшифровки захваченного ранее трафика.
Причина — ephemeral key exchange:
Сессия №1 → ephemeral key A → session secret A (уничтожен)
Сессия №2 → ephemeral key B → session secret B (уничтожен)
Сессия №3 → ephemeral key C → session secret C (уничтожен)
Долгосрочный certificate private key используется только для подписи в CertificateVerify — доказательства владения. Session secrets выводятся из ephemeral ECDHE ключей, которые уничтожаются после сессии. Компрометация сертификата позволяет атакующему выдать себя за сервер в будущих соединениях, но не расшифровать прошлый трафик. Фраза «украли SSL-сертификат — значит расшифровали весь трафик» — неверная ментальная модель для нормально настроенного TLS 1.3.
Рынок 2026: что ищут работодатели
TLS редко фигурирует как самостоятельный навык. На просторах профильных площадок в вакансиях для сетевой безопасности рядом с TLS/PKI регулярно появляются Linux, SIEM, NGFW, Cisco, IDS, анализ логов и мониторинг. В вакансии SOC L2 по сетевой безопасности требуются Linux, SIEM, NGFW, Cisco, анализ логов сетевого оборудования и интеграция NTA/Suricata. Security всё чаще находится на стыке сети, инфраструктуры и разработки.
Есть и более узкий PKI-сегмент: вакансия Team Lead Go для продукта управления инфраструктурой и PKI (TLS/ГОСТ) включает Go, Kubernetes, PostgreSQL, ClickHouse, Kafka, TCP, DNS и Linux. Вилка — 450-600 тыс. ₽.
Полезно разделить стек по уровням.
Middle security/network:
TCP/IP, DNS, HTTP/HTTPS;
TLS/PKI;
Linux;
Wireshark/tcpdump;
firewall/NGFW, VPN;
SIEM;
базовая автоматизация Python/Bash.
Senior/Infrastructure Security:
PKI и certificate lifecycle;
mTLS, reverse proxy / load balancer, TLS termination;
Kubernetes ingress, service mesh;
secrets management, observability;
automation/IaC, cloud networking;
incident response, threat modeling.
Что точно не стоит продавать как «современный TLS stack»: SSLv2/3, TLS 1.0/1.1, RSA key exchange, старые DH-группы, RC4, CBC как предпочтительный режим, SHA-1/MD5 в новых конфигурациях.
На стыке offensive security и сетевого анализа находится понимание модели атаки: что именно угрожает TLS-соединению, как выглядит MITM и как анализировать трафик не только для отладки, но и для обнаружения аномалий. Этот уровень — MITM, анализ трафика, penetration testing, сетевые протоколы — разбирает программа ProductStar
«Профессия Белый хакер + ИИ». Она значительно шире TLS: 9 месяцев, полный pentest-трек, около 60 134 ₽ согласно каталогу Хабр Курсов Для тех, кому нужен исключительно TLS/PKI engineering, большая часть программы будет избыточной — но для построения security mindset в части сетевых атак это полноценный трек.
Подробности — в каталоге Хабр Курсов
Где закрыть пробелы в инфраструктурной безопасности
TLS не существует отдельно. В production он соседствует с firewall, VPN, мониторингом, packet analysis и контролем доступа. После понимания handshake полезно увидеть TLS как часть общей security architecture.
Программа профессиональной переподготовки Айтиком Академии «Информационная безопасность». Техническая защита конфиденциальной информации» охватывает криптографию, Wireshark, Nmap, tcpdump, OpenVPN, firewall, iptables, TCP/DNS/HTTP, SSH, мониторинг и анализ защищённости.
Программа широкая, ориентированная на комплексную техническую защиту информации: для опытного инженера, которому нужен исключительно TLS 1.3/PKI, она будет избыточной. Формат — 14-16 недель; стоимость стоит уточнять в карточке программы на Хабр Курсах, поскольку данные в каталоге расходятся.
