TLS лежит на пути почти каждого внешнего запроса: он согласует ключи в рукопожатии, проверяет сертификат сервера и дальше шифрует каждый байт приложения. От его версии, набора шифров и числа перелётов напрямую зависят задержка первого запроса, устойчивость к перехвату и стоимость нового соединения.
На практике инженеру важно отличать механику протокола от криптографических основ: где TLS живёт в стеке, чем 1-RTT рукопожатие TLS 1.3 отличается от 2-RTT в 1.2, как строится цепочка до корневого CA, как работают session tickets и почему 0-RTT опасен для неидемпотентных операций. Эта глава разбирает именно поведение «по проводу».
На интервью по System Design это даёт конкретный язык: объяснить рост задержки через перелёты рукопожатия, обосновать выбор между совместимостью и безопасностью, описать mTLS как фундамент service mesh и нулевого доверия и быстро отличить сетевой инцидент от просроченного сертификата.
Практическая польза главы
Бюджет задержки
Перелёты рукопожатия напрямую формируют время до первого байта; 1-RTT в TLS 1.3 и возобновление сессии — конкретные рычаги ускорения внешних запросов.
Безопасность по умолчанию
Forward secrecy, AEAD-шифры и проверка цепочки сертификатов становятся базовой линией, а не опцией; видно, что и зачем убрали в 1.3.
Диагностика инцидентов
Помогает за минуту отличить просроченный сертификат, несовпадение имени или неполную цепочку от настоящего сетевого сбоя.
Доверие между сервисами
mTLS объясняется как фундамент service mesh и нулевого доверия, а не как экзотическая настройка.
RFC
RFC 8446 (TLS 1.3)
Актуальная спецификация TLS 1.3: формат рукопожатия, ключевой обмен только через (EC)DHE и AEAD-шифры.
воспринимают как «галочку про шифрование», но в реальной системе он решает три задачи сразу: согласует ключи в рукопожатии, проверяет сертификат сервера и потом шифрует каждый байт приложения. От его версии, набора шифров и числа перелётов зависит, сколько миллисекунд добавится к первому запросу, сможет ли посредник подменить ответ и во что обходится каждое новое соединение.
Эта глава — про именно как про сетевой протокол: где он живёт в стеке, как устроены рукопожатие и record layer, чем отличаются версии 1.2 и 1.3, как проверяется цепочка сертификатов, какие бывают расширения и как работает возобновление сессии. Здесь мы разбираем механику «по проводу», а не сами криптографические примитивы.
Криптографические основы — асимметричное шифрование, цифровые подписи, , устройство PKI, жизненный цикл и — подробно разобраны в соседней главе «Шифрование, ключи и TLS на практике». Здесь мы опираемся на них как на фундамент и не дублируем теорию, а смотрим, как протокол использует её во время реального соединения.
В системном дизайне лежит на пути почти каждого внешнего запроса, поэтому его внутренности всплывают на разборах инцидентов чаще, чем хотелось бы. Знание перелётов, цепочки до и поведения при возобновлении сессии помогает не путать сетевую деградацию с протухшим сертификатом и осознанно выбирать компромисс между совместимостью со старыми клиентами и текущими требованиями безопасности.
Что именно защищает TLS
Конфиденциальность
После рукопожатия прикладные данные шифруются симметричным алгоритмом — посредник на пути видит только зашифрованный поток и не может прочитать содержимое.
Целостность
Каждая запись защищена кодом аутентификации. Если кто-то по дороге поменял хотя бы байт, принимающая сторона это обнаружит и разорвёт соединение.
Аутентификация сервера
Клиент строит цепочку сертификатов до доверенного корня и так убеждается, что говорит именно с заявленным сервером, а не с подставным.
Опционально — аутентификация клиента
Режим mTLS добавляет вторую сторону: сервер тоже требует и проверяет клиентский сертификат, и доверие становится двусторонним.
Где живёт TLS: record layer между транспортом и приложением
— это надстройка над надёжным транспортом. Снизу он опирается на упорядоченный байтовый поток , а сверху отдаёт приложению уже расшифрованные данные, будто канал изначально безопасен.
Где TLS живёт в стеке
между транспортом и приложениемПриложение (HTTP, gRPC, почтовые протоколы)
Передаёт и получает уже расшифрованные байты, как будто канал прозрачен.
TLS: handshake + record layer
Согласует ключи в рукопожатии и шифрует прикладные данные в записях с тегом аутентификации.
Транспорт (TCP)
Обеспечивает упорядоченный надёжный байтовый поток, поверх которого живёт TLS.
Сеть (IP)
Доставляет пакеты между узлами; о шифровании и сессии ничего не знает.
не относится к транспорту: он надстройка над надёжным потоком, которая добавляет шифрование, целостность и аутентификацию, оставляя доставку самому .
Как устроен record layer
- Прикладные байты режутся на записи (TLS records); каждая запись шифруется и снабжается тегом аутентификации.
- Поверх record layer работает отдельный handshake-протокол — он согласует версию, ключи и параметры сессии.
- Транспорт TLS не заменяет: упорядочивание и повторную передачу по-прежнему обеспечивает протокол TCP под ним.
- Из этого следует неприятное свойство: потеря одного TCP-сегмента задерживает расшифровку всей записи, и TLS наследует поведение транспорта при потерях.
RFC
RFC 5246 (TLS 1.2)
Спецификация TLS 1.2: порядок сообщений рукопожатия, ServerKeyExchange и Finished. Обновлена RFC 8446, но всё ещё широко развёрнута.
Рукопожатие: TLS 1.2 против TLS 1.3
Рукопожатие — сердце протокола: стороны согласуют версию и , обмениваются ключевым материалом, сервер доказывает свою личность сертификатом, и только потом открывается шифрованный канал. Главное различие версий — число перелётов до первых прикладных данных и набор разрешённых способов обмена ключами.
TLS 1.2 — полное рукопожатие
2-RTTClientHello
Клиент шлёт поддерживаемые версии, список cipher suites, случайное значение и расширения (SNI, ALPN).
ServerHello + сертификат
Сервер выбирает версию и cipher suite, присылает свой сертификат и при ECDHE — параметры обмена ключами (ServerKeyExchange).
Обмен ключами + Finished
Клиент проверяет цепочку, отправляет свою часть обмена ключами, ChangeCipherSpec и зашифрованный Finished.
Finished
Сервер подтверждает согласованные ключи своим Finished. Только после этого начинается обмен прикладными данными.
TLS 1.3 — полное рукопожатие
1-RTTClientHello + key_share
Клиент сразу присылает свою долю эфемерного ключа (key_share) для предполагаемой группы (EC)DHE вместе со списком cipher suites и расширениями.
ServerHello + сертификат + Finished
Сервер отвечает своей долей ключа, переключает запись в шифрованный режим, присылает сертификат, проверку подписи и Finished — всё в одном перелёте.
Finished + данные
Клиент проверяет цепочку и подпись, шлёт свой Finished и уже первые прикладные данные. Итог — полное рукопожатие за 1-RTT.
В TLS 1.2 полное рукопожатие занимает два круга до первого байта приложения. В TLS 1.3 клиент присылает свою долю ключа уже в ClientHello, поэтому полное рукопожатие укладывается в один RTT.
Что TLS 1.3 выпилил из 1.2 и почему
RFC 8446 не только ускорил рукопожатие. Из протокола убрали целый класс опасных режимов: статический RSA и статический (EC)DH удалены, остался только эфемерный (EC)DHE или PSK. Это и означает forward secrecy по умолчанию — утечка приватного ключа сервера в будущем уже не раскрывает трафик, записанный сегодня.
Раунды рукопожатия
TLS 1.2: Полное рукопожатие — 2-RTT до первых прикладных данных.
TLS 1.3: Полное рукопожатие — 1-RTT; возобновление сессии допускает 0-RTT.
Обмен ключами
TLS 1.2: Допускались статический RSA и статический (EC)DH без forward secrecy.
TLS 1.3: Только эфемерный (EC)DHE или PSK — forward secrecy по умолчанию.
Шифры
TLS 1.2: Смесь AEAD и устаревших режимов: CBC, RC4, MAC-then-Encrypt.
TLS 1.3: Только AEAD: AES-GCM, ChaCha20-Poly1305, AES-CCM.
Защита рукопожатия
TLS 1.2: Сертификат и часть сообщений передаются открытым текстом.
TLS 1.3: После ServerHello рукопожатие шифруется, включая сертификат сервера.
Связанная глава
Шифрование, ключи и TLS на практике
Криптографические основы, устройство PKI и жизненный цикл сертификатов, на которые опирается проверка цепочки.
Сертификаты и проверка цепочки
Аутентификация сервера держится на проверке и построении до доверенного корня. Пропустишь любой шаг проверки — и шифрование остаётся защитой только от случайного наблюдателя, но не от целенаправленной атаки с подменой сертификата.
Цепочка до корня
Сервер присылает свой лист-сертификат и промежуточные; клиент достраивает путь до корневого CA из локального хранилища доверия.
Проверка подписи
Каждое звено цепочки подписано вышестоящим CA. Клиент проверяет подписи и базовые ограничения (basicConstraints, keyUsage) — без этого сертификат с лишними правами легко превращается в лазейку.
Совпадение имени хоста
Имя из запроса сверяется с полем SAN сертификата (Subject Alternative Name). Несовпадение — это сигнал об атаке или неверной конфигурации, и строгий клиент обязан разорвать соединение.
Срок и отзыв
Сверяются notBefore/notAfter и статус отзыва через OCSP или CRL. OCSP stapling позволяет серверу приложить свежий подписанный статус прямо к рукопожатию и не гонять клиента к центру сертификации (CA).
Отзыв проверяется через или . OCSP stapling позволяет серверу приложить свежий подписанный статус прямо в рукопожатие и не гонять клиента к стороннему сервису CA.
Наборы шифров (cipher suites) и обмен ключами
Forward secrecy через ECDHE
Эфемерный ключевой обмен ECDHE генерирует новую пару ключей на каждое соединение. Сессионный ключ не выводится напрямую из долгоживущего ключа сервера, поэтому его компрометация в будущем не раскрывает прошлый трафик — это и есть forward secrecy. В TLS 1.3 это единственный режим обмена ключами.
AEAD: шифрование плюс целостность
Прикладные данные защищает AEAD-шифр, который за один проход даёт и конфиденциальность, и целостность. TLS 1.3 оставил только AEAD: обязательным к реализации является TLS_AES_128_GCM_SHA256, а также рекомендованы TLS_AES_256_GCM_SHA384 и TLS_CHACHA20_POLY1305_SHA256.
В 1.2 задавал сразу всё — обмен ключами, аутентификацию, шифр и MAC — и среди вариантов оставались небезопасные режимы. В 1.3 имя набора описывает только AEAD-шифр и хеш, а способ обмена ключами и подписи согласуется отдельными расширениями, что резко сократило пространство опасных комбинаций.
Источник
An overview of TLS 1.3 (Cloudflare)
Разбор Cloudflare про 1-RTT и 0-RTT в TLS 1.3, риск повторного воспроизведения и удалённые из протокола устаревшие механизмы.
Производительность, возобновление и расширения
Главная цена TLS — это перелёты рукопожатия, которые ложатся прямо на время до первого байта. Возобновление сессии и расширения существуют ровно для того, чтобы эту цену снизить и при этом не открыть новых дыр.
Цена RTT рукопожатия
Каждый перелёт рукопожатия добавляет один RTT к первому байту. На дальних маршрутах TLS 1.3 с 1-RTT заметно выигрывает у 2-RTT в 1.2 — особенно для коротких HTTPS-запросов, где сам ответ короче рукопожатия.
Возобновление сессии
Session tickets дают пропустить полное рукопожатие: стороны восстанавливают сессию по заранее согласованному PSK и экономят как минимум один перелёт.
0-RTT и риск повтора
При возобновлении в 1.3 клиент может отправить данные ещё до ответа сервера, но за это платит безопасностью: такие данные не защищены от повторного воспроизведения (replay) и не дают forward secrecy.
SNI и ALPN
SNI сообщает имя хоста, чтобы сервер выбрал нужный сертификат; ALPN внутри рукопожатия согласует прикладной протокол (h2 или h3) за тот же проход — без отдельного раунда переговоров.
Осторожно с 0-RTT. Ранние данные не дают forward secrecy и могут быть воспроизведены повторно, поэтому через 0-RTT допустимы только идемпотентные операции — никаких переводов денег или изменяющих состояние запросов.
Связанная глава
Zero Trust: архитектура нулевого доверия
Как mTLS даёт криптографическую идентичность рабочих нагрузок вместо доверия к сетевому периметру.
mTLS: взаимная аутентификация
Обычный TLS аутентифицирует только сервер. В клиент тоже предъявляет сертификат, и доверие становится двусторонним — это ключевой механизм для внутреннего трафика между сервисами.
- В mTLS клиент тоже предъявляет сертификат, а сервер проверяет его цепочку — обе стороны аутентифицируют друг друга, и общий секрет в коде больше не нужен.
- Это базовый кирпич service mesh: трафик между сервисами шифруется и взаимно аутентифицируется автоматически, без паролей и токенов в конфигах.
- Архитектура нулевого доверия использует mTLS как криптографическую идентичность рабочей нагрузки — доверие привязано к ключу, а не к подсети или IP.
- Платить за это приходится управлением жизненным циклом клиентских сертификатов: выпуск, короткие сроки и автоматическая ротация ложатся на плечи платформы.
Эксплуатация: ротация, downgrade и наблюдаемость
- Сертификаты живут конечное время, поэтому должна быть автоматической: ручной выпуск рано или поздно забывают, и сервис падает на истечении.
- Защита от downgrade: отключайте устаревшие версии и слабые шифры, чтобы посредник не мог принудительно откатить соединение к уязвимому набору параметров.
- Для конфигурации опирайтесь на проверенные профили (например, Mozilla Server Side TLS), а не подбирайте вручную — так меньше шансов оставить опасную комбинацию.
- Наблюдаемость: следите за сроками сертификатов, долей рукопожатий по версиям и ошибками проверки цепочки — это ранний сигнал и инцидентов, и медленной деградации.
Почему это важно для системного дизайна
- Перелёты рукопожатия ложатся напрямую на первого запроса — и тем заметнее, чем длиннее маршрут до сервера.
- Выбор версии и шифров — это всегда компромисс между совместимостью со старыми клиентами и безопасностью текущих соединений.
- Возобновление сессии и 0-RTT экономят , но требуют аккуратности с идемпотентностью: ранние данные могут быть повторены.
- превращает TLS в механизм идентичности рабочих нагрузок и становится фундаментом и нулевого доверия.
Частые ошибки
Несовпадение имени хоста: сертификат выписан на другое имя или не содержит нужный SAN — строгий клиент обоснованно рвёт соединение, и пользователь видит ошибку.
Забытая ротация и протухший сертификат: один пропущенный календарь роняет весь сервис разом, потому что клиенты массово перестают доверять соединению.
Неполная цепочка: сервер отдаёт только лист и забывает про промежуточные, и часть клиентов не может достроить путь до корневого CA.
Разрешённый откат версии: поддержка устаревших версий и слабых шифров открывает дорогу downgrade-атакам и компрометации текущей сессии.
Источники и материалы
Карта источников: RFC 8446 — нормативная опора для TLS 1.3; RFC 5246 нужен для контраста с TLS 1.2; RFC 6066 закрывает SNI/OCSP-расширения. Cloudflare и Mozilla ниже — практические комментарии и профили конфигурации: они полезны для эксплуатации, но cipher suites и совместимость всегда надо сверять с текущим парком клиентов.
- RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3 — спецификация TLS 1.3: 1-RTT, обмен ключами только через (EC)DHE и forward secrecy по умолчанию.
- RFC 5246 — The Transport Layer Security (TLS) Protocol Version 1.2 — порядок сообщений рукопожатия 1.2; обновлена RFC 8446, но всё ещё широко развёрнута.
- RFC 6066 — TLS Extensions: Extension Definitions — расширения TLS, включая Server Name Indication (SNI) и status_request (OCSP).
- Cloudflare — An overview of TLS 1.3 and Q&A — разбор 1-RTT и 0-RTT, риска повторного воспроизведения и удалённых устаревших механизмов.
- Mozilla — SSL Configuration Generator (профили Modern/Intermediate/Old) — практические профили конфигурации (Modern, Intermediate, Old) с AEAD-шифрами и forward secrecy.
Связанные главы
- Протокол TCP - разбирает транспорт под TLS: рукопожатие, повторные передачи и задержки, которые TLS наследует поверх соединения и не может починить сам.
- Протокол HTTP - показывает прикладной слой над TLS — в том числе то, как ALPN ещё в рукопожатии выбирает между HTTP/2 и HTTP/3 без отдельного раунда.
- Шифрование, ключи и TLS на практике - соседняя глава про криптографические основы, PKI и жизненный цикл ключей — фундамент, на котором стоит этот протокол.
- Zero Trust: архитектура нулевого доверия - объясняет, как mTLS заменяет доверие к периметру криптографической идентичностью рабочей нагрузки.