Возобновление 0-RTT и шифрование пакетов

Пользователь повторно посещает сайт, на котором был вчера. В браузере есть сессионный тикет. QUIC отправляет HTTP-запрос в самом первом пакете — ноль RTT — до того, как сервер вообще ответит. Но если злоумышленник перехватит и воспроизведёт этот первый пакет, сервер выполнит запрос дважды.

Механика возобновления 0-RTT

При повторных подключениях к тому же серверу клиент может переиспользовать кешированный сессионный тикет — зашифрованный блоб TLS-состояния, выданный сервером в конце предыдущего соединения. Клиент включает этот тикет в ClientHello и прикрепляет данные приложения (0-RTT данные) в том же Initial-пакете.

Сервер получает Initial, расшифровывает сессионный тикет (содержащий ключи возобновления) и может немедленно обработать 0-RTT данные — без ожидания полного рукопожатия.

Задержка: 0 RTT до обработки сервером первого запроса. На линии 100 ms это экономит 100 ms при переподключении — поверх 100 ms, уже сэкономленных 1-RTT рукопожатием против TCP+TLS.

Уязвимость реплея

0-RTT данные шифруются симметричным ключом сессионного тикета. Злоумышленник на пути захватив Initial-пакет, может позже воспроизвести весь пакет серверу. Поскольку у 0-RTT нет защиты от реплея на уровне TLS-записи, сервер получит и обработает воспроизведённый запрос.

Конкретная атака: Алиса отправляет POST /api/transfer amount=5000 from=alice to=bob в 0-RTT. Злоумышленник захватывает и воспроизводит пакет. Сервер выполняет перевод дважды: Алиса теряет 10 000 вместо 5 000.

Защита:

1. Ограничить 0-RTT только идемпотентными запросами. GET, HEAD и безопасные операции — безопасны; воспроизведение даёт тот же результат. POST, DELETE и изменяющие состояние операции должны ждать 1-RTT ключей.
2. Ответ 425 Too Early. Когда сервер перенаправляет 0-RTT на origin-backend, он включает заголовок Early-Data: 1. Origin может ответить 425 (Too Early), принуждая клиента повторить после полного рукопожатия (RFC 8470).
3. Изоляция сессионных тикетов. Серверы не должны делиться ключами сессионных тикетов между датацентрами — тикет от Server A должен быть действителен только на Server A. Короткое время жизни тикетов (1–24 часа) ограничивает окно реплея.

Почти полное шифрование пакетов

TCP-заголовки открыты — исходный/целевой IP, порты, порядковые номера видны любому наблюдателю. QUIC шифрует почти всё:

Длинные заголовки (рукопожатие и Initial-пакеты):

• Незашифровано: внешние 4 байта (версия + длина Connection ID) и сам Connection ID.
• Зашифровано: номер пакета, полезная нагрузка — соответствующим ключом уровня.

Короткие заголовки (постхендшейковые пакеты):

• Несут только Connection ID и зашифрованный номер пакета + полезную нагрузку.
• Почти полностью непрозрачны для наблюдателей.

Последствия для безопасности:

• Злоумышленник на пути не может внедрить RST-пакеты — без 1-RTT ключа нельзя сконструировать валидный зашифрованный пакет. Уязвимость TCP к RST-инъекции устранена.
• Пассивный сниффинг содержимого потоков устранён — все данные потоков шифруются 1-RTT.
• Анализ трафика на основе порядковых номеров невозможен без расшифровки.

Операционное последствие: tcpdump QUIC-трафика показывает только непрозрачные блобы. Сетевые инженеры не могут подсчитать HTTP-запросы на endpoint, идентифицировать медленных клиентов или обнаружить некорректное поведение на уровне пакетов без инструментации на уровне приложения.