Сети и протоколы
TLS 1.3: обзор с выбором ответа
Суть Синтез-вопросы с выбором по юниту TLS 1.3: handshake за 1 RTT, forward secrecy, PSK-возобновление, replay 0-RTT, разделение cipher suite и ECH.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов сквозь весь юнит. Каждый отражает решение, которое ты принимаешь, проектируя или отлаживая TLS-развёртывание, — не определение для заучивания, а компромисс между скоростью, секретностью и защитой от replay.
Цель
Убедись, что умеешь связать handshake за 1 RTT, forward secrecy, возобновление сессии, риск replay в 0-RTT, разделение cipher suite и приватность SNI — тот синтез, к которому вели отдельные уроки.
Викторина
Completed
TLS 1.2 требовал двух round-trip для холодного handshake; TLS 1.3 — одного. Какое единственное изменение дизайна свернуло RTT и почему Perfect Forward Secrecy появляется бесплатно?
Heads-up Проверка сертификата по-прежнему происходит в 1-RTT — она зашифрована под handshake-ключом в том же проходе. RTT сэкономлен переносом key_share в ClientHello, а не отказом от аутентификации.
Heads-up Наоборот: TLS 1.3 убрал RSA key transport. Именно RSA transport разрушает forward secrecy, потому что украденный долгоживущий ключ расшифровывает все записанные прошлые сессии.
Heads-up Размер сертификата не связан с числом RTT. Экономия round-trip достигается ранним размещением ECDHE key_share, что позволяет серверу сразу вывести секрет.
Викторина
Completed
Тёплый handshake с возобновлением по PSK полностью пропускает проверку сертификата. Как клиент всё ещё знает, что говорит с легитимным сервером, а не с самозванцем?
Heads-up Возобновление аутентифицировано: сам PSK является удостоверением. Использовать его может только сервер, владеющий ключом шифрования session ticket (STEK).
Heads-up При возобновлении нет повторной загрузки сертификата — в этом весь смысл пропуска затрат PKI. Доказательством личности служит PSK.
Heads-up DNSSEC не связан с возобновлением TLS. Аутентификация переносится из исходного handshake через PSK.
Викторина
Completed
Инженер включил 0-RTT глобально ради задержки. Через неделю финансы сообщают о периодических дублирующихся переводах. Какова первопричина и верное исправление?
Heads-up 0-RTT использует те же AEAD-шифры, что и данные 1-RTT. Дефект — это replay, а не стойкость шифра: один и тот же валидный ciphertext можно доставить более одного раза.
Heads-up Истечение тикета вызывает свежий handshake, а не дублированную мутацию. Дубликат — это replay early data, обработанной приложением дважды.
Heads-up PSK-возобновление подходит для любого метода; именно early data в 0-RTT поддаётся replay. Исправление — политика идемпотентности на уровне маршрута плюс 425 Too Early, а не отключение возобновления.
Викторина
Completed
В TLS 1.3 cipher suite TLS_AES_128_GCM_SHA256 больше не называет обмен ключами или алгоритм подписи — в отличие от TLS 1.2. Что дало это разделение?
Heads-up Смена в середине соединения — это KeyUpdate, который переиспользует тот же suite. Разделение касается осей согласования, а не смены suite во время сессии.
Heads-up RSA key transport полностью убран в TLS 1.3. Разделённые оси — named group, signature algorithm и AEAD+хеш, и все они дают forward-secret обмен ключами.
Heads-up TLS 1.3 допускает только AEAD-шифры; CBC-режим и комбинации MAC-then-encrypt убраны. Разделение их не возвращает.
Викторина
Completed
Middlebox переписывает список ALPN в ClientHello, убирая 'h2', чтобы навязать HTTP/1.1. Соединение обрывается до передачи данных. Почему?
Heads-up ALPN находится в открытом ClientHello, так что middlebox может его читать и менять — но он всё равно входит в transcript hash, поэтому правка обнаруживается по MAC в Finished.
Heads-up IP источника ни при чём. Обрыв — это несовпадение HMAC в Finished из-за изменённого transcript, что и делает handshake TLS 1.3 устойчивым к подделке.
Heads-up HTTP/1.1 прекрасно работает поверх TLS 1.3. Отказ — это проверка целостности transcript, а не ограничение версии протокола.
Викторина
Completed
Security review отмечает, что корпоративный прокси всё ещё может логировать, какие хосты посещают сотрудники, даже на TLS 1.3. Какой механизм это раскрывает и что закрывает брешь?
Heads-up В TLS 1.3 сообщение Certificate зашифровано под handshake-ключом — SAN не виден. Открытая утечка — это SNI в ClientHello, что и решает ECH.
Heads-up OCSP stapling убирает утечку приватности живого OCSP, но имя хоста всё ещё раскрыто через открытый SNI. Закрыть эту брешь может ECH, а не stapling.
Heads-up TLS 1.3 не шифрует ClientHello по умолчанию; SNI, ALPN и supported groups видны. ECH — это опциональное расширение, шифрующее чувствительный внутренний hello.
Итог
Сквозная линия юнита — одна цепочка компромиссов: ECDHE key_share в ClientHello даёт handshake за 1 RTT и forward secrecy вместе; PSK-возобновление меняет свежую аутентификацию на скорость, но остаётся аутентифицированным через тикет; 0-RTT меняет round-trip на уязвимость к replay, сдерживаемую только идемпотентностью плюс 425 Too Early; разделение cipher suite сжимает поверхность атаки до пяти suite; а transcript hash делает каждый согласованный параметр устойчивым к подделке. SNI всё ещё раскрывает имя хоста, пока его не зашифрует ECH. Скорость, секретность и защита от replay — три оси, которые ты балансируешь в каждом решении по TLS.