Постквантовый TLS упирается в первые 15 килобайт

Переход на постквантовую криптографию обычно описывают как замену алгоритмов: RSA и эллиптические кривые нужно убрать, ML-KEM и ML-DSA — поставить. Для сетевого инженера эта формулировка скрывает главную проблему. Новый алгоритм надо не только вычислить. Его открытые ключи, подписи и сертификаты ещё нужно передать по сети — причём в первые мгновения соединения, когда транспортный протокол намеренно ограничивает отправителя.

Постквантовый TLS упирается не в пропускную способность уже установленного туннеля. Он упирается в первые пакеты, первые подтверждения и первые 15 килобайт.

Это не означает, что интернет придётся строить заново. Но привычная замена сертификата «один алгоритм на другой» перестаёт быть локальным криптографическим обновлением. Она меняет поведение TCP и QUIC, время установления соединения, чувствительность к потерям и требования к промежуточным устройствам.

Переход уже начался, но пока только наполовину

В TLS 1.3 есть две разные криптографические задачи.

Первая — договориться о ключе сеанса. Для неё уже применяется гибридная схема X25519MLKEM768: классический X25519 работает вместе с постквантовым ML-KEM. Google включил гибридный обмен ключами для Chrome, поддержку разворачивают крупные облачные и CDN-провайдеры.

Вторая задача — проверить подлинность сервера. Здесь участвуют сертификаты X.509 и цифровые подписи. Именно этот этап оказался сложнее для массовой миграции. Использование ML-DSA в TLS 1.3 всё ещё оформляется в IETF как рабочий проект стандарта, а инфраструктуре предстоит переварить заметно более крупные ключи и подписи.

Гибридный обмен ключами защищает записанный сегодня трафик от расшифровки в будущем. Но пока сервер аутентифицируется только классической подписью, полноценного постквантового TLS ещё нет.

Что именно раздувается

В упрощённом виде серверная часть TLS 1.3 выглядит так:

ServerHello
EncryptedExtensions
Certificate
CertificateVerify
Finished

В Certificate лежит не один открытый ключ, а сертификат сервера и обычно один или несколько промежуточных сертификатов. Каждый сертификат подписан его издателем. В CertificateVerify сервер отдельно подписывает контекст текущего рукопожатия и доказывает, что владеет закрытым ключом.

Для ECDSA P-256 подпись занимает примерно 64 байта. У ML-DSA-44 подпись занимает 2420 байт, а открытый ключ — 1312 байт. Эти размеры зафиксированы в стандарте NIST FIPS 204. Одна подпись становится почти в 38 раз больше.

Алгоритм	Открытый ключ	Подпись
ECDSA P-256	65 байт для несжатой точки	около 64 байт
ML-DSA-44	1312 байт	2420 байт

И это только криптографическое содержимое. Сверху добавляются ASN.1, поля X.509, имена, расширения, данные Certificate Transparency, OCSP и служебные поля TLS.

Количество подписей в соединении нельзя считать постоянным. Оно зависит от длины цепочки и конфигурации сервера. В одном из реальных примеров Cloudflare насчитал шесть подписей: две в цепочке сертификатов, одну в CertificateVerify, одну в OCSP-ответе и две в SCT для Certificate Transparency. Там же передавались два открытых ключа. Если мысленно заменить всё это на ML-DSA-44, только ключи и подписи займут:

6 × 2420 + 2 × 1312 = 17 144 байта

Не каждый будущий handshake будет устроен именно так, и не все элементы мигрируют одновременно. Но порядок величины понятен: несколько десятков или сотен байт превращаются в десятки килобайт ещё до полезной нагрузки приложения.

Почему критичны 14,6 килобайта

TCP не начинает новое соединение с отправки неограниченного объёма данных. Сначала он осторожно проверяет, сколько сеть способна принять без перегрузки.

RFC 6928 предложил начальное окно до десяти TCP-сегментов. При обычном Ethernet получается знакомая оценка:

MTU = 1500 байт
MSS ≈ 1460 байт
Initial Window = 10 MSS

10 × 1460 = 14 600 байт

Это не предел размера сертификата, TLS-сообщения или TCP-соединения. Это объём, который сервер обычно может держать «в полёте» в начале передачи, не получив подтверждений клиента.

Если серверная часть рукопожатия укладывается в начальное окно, она может уйти одной серией пакетов:

Сервер  →  клиент: Certificate + CertificateVerify + Finished
Клиент  →  сервер: подтверждение

Если не укладывается, хвост ждёт освобождения окна:

Сервер  →  клиент: первые ≈14,6 КБ
Клиент  →  сервер: подтверждение
Сервер  →  клиент: остаток рукопожатия

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

Важно и то, что десять сегментов — распространённый ориентир, а не обещание для любого стека. Реальная величина окна зависит от операционной системы, настройки сервера и истории соединения. CDN может использовать окно больше. После потерь стек, наоборот, может вести себя осторожнее. Поэтому 14,6 КБ — полезная инженерная граница, но не универсальная константа интернета.

Больше пакетов — больше возможностей потерять один

Предположим, сервер должен отправить 18 КБ данных рукопожатия. При MSS около 1460 байт это примерно 13 TCP-сегментов. В начальное окно из десяти сегментов они уже не помещаются.

Даже до пересечения этой границы дополнительные байты не бесплатны. Их нужно передать по каналу, поставить в очереди и при необходимости отправить заново. Полевой эксперимент Cloudflare с искусственно увеличенными TLS-рукопожатиями показал две разные причины задержки: постепенный рост времени по мере добавления пакетов и отдельный скачок после заполнения начального окна. В их инфраструктуре увеличение рукопожатия на 35 КБ повысило медианное время примерно на 40%, хотя данные ещё помещались в увеличенное окно CDN. Для обычного окна из десяти сегментов авторы ожидали существенно более ранний скачок.

Хуже всего сочетание факторов:

высокий RTT;
низкая пропускная способность;
потери пакетов;
мобильные и радиосети;
перегруженные VPN-туннели;
большое количество коротких TLS-соединений;
старые NAT, межсетевые экраны и прокси, которые плохо переносят непривычно крупные сообщения.

Большой handshake не обязательно сломает соединение. Чаще он просто ухудшит его хвостовые задержки: большинство пользователей ничего не заметит, а несколько процентов на плохих каналах получат резкий рост времени открытия или тайм-аут.

В QUIC нет TCP-окна, но есть другой потолок

HTTP/3 работает поверх QUIC и UDP, поэтому механика там другая. Однако до проверки адреса клиента сервер обязан защищаться от использования в атаках с усилением трафика.

RFC 9000 запрещает серверу отправлять на непроверенный адрес больше трёх объёмов данных, которые он получил с этого адреса. Первая UDP-дейтаграмма клиента с QUIC Initial должна иметь полезную нагрузку не меньше 1200 байт. Если клиент прислал только такой минимум, у сервера есть бюджет порядка 3600 байт до подтверждения адреса.

Обычная цепочка ещё может приблизиться к этому бюджету. Постквантовая — легко его превышает. Тогда сервер не имеет права немедленно отправить весь TLS-handshake: ему нужно получить от клиента дополнительные данные или заранее проверить адрес с помощью токена и Retry.

QUIC при этом не обязан фрагментировать IP-пакеты. Он сам раскладывает криптографические данные по фреймам и UDP-дейтаграммам. Проблема не в невозможности нарезать большой сертификат, а в том, что до проверки адреса весь этот объём нельзя сразу выпустить в сеть.

Получается неприятная симметрия:

в TCP большой handshake упирается в начальное окно перегрузки;
в QUIC он упирается в предел усиления до проверки адреса.

Протоколы разные, а результат похож: дополнительные сетевые обмены до начала полезной работы.

Почему нельзя просто увеличить начальное окно

На отдельном сервере увеличить TCP initial congestion window возможно. Крупные CDN так делают. Но как план мировой миграции это слабое решение.

Во-первых, окно управляет не только TLS. Его увеличение меняет стартовое поведение всех TCP-соединений и увеличивает объём данных, который хост одномоментно выбрасывает в ещё не изученную сеть.

Во-вторых, это не отменяет стоимость передачи по медленному каналу и повторной передачи потерянных пакетов.

В-третьих, настройка TCP не снимает ограничение QUIC до проверки адреса.

В-четвёртых, на время перехода часто нужны гибридные схемы: классический и постквантовый алгоритмы работают вместе, пока вся экосистема не научилась доверять новому. Совместимость повышается, но рукопожатие становится ещё больше.

Наконец, интернет — это не только браузер и веб-сервер последней версии. Между ними стоят балансировщики, средства расшифровки трафика, VPN, NAT, системы предотвращения вторжений и встроенные устройства. Некоторые из них годами не встречали таких сертификатов. Их отказ нельзя исправить одной настройкой на сервере.

Настоящая проблема перехода — архитектурная

Постквантовую миграцию нельзя свести к закупке новой версии криптографической библиотеки. Придётся заново проверить несколько уровней сразу:

PKI. Какие цепочки сертификатов будут передаваться, сколько в них промежуточных центров, где останутся классические подписи и как будет устроено гибридное доверие.
TLS. Какие клиенты поддерживают ML-DSA, как сервер выбирает сертификат и что происходит при откате на классическую аутентификацию.
Транспорт. Помещается ли рукопожатие в начальное окно TCP и антиамплификационный бюджет QUIC.
Сеть. Как меняются задержки и потери на мобильных каналах, через VPN и при малом MTU.
Промежуточные устройства. Не обрывают ли соединения старые прокси, балансировщики, NAT и средства анализа трафика.
Приложение. Сколько коротких соединений оно открывает, использует ли повторное подключение и возобновление TLS-сессий, можно ли сократить число рукопожатий.

Проверять это нужно не только на гигабитном канале внутри лаборатории. Полезный стенд должен уметь добавлять RTT, ограничивать полосу, терять пакеты и воспроизводить реальные размеры цепочек. Измерять стоит не только среднее время, но и 95-й и 99-й процентили, долю неуспешных рукопожатий и время до первого байта.

Иначе пилот покажет, что ML-DSA «работает», а после массового включения проблема проявится только у пользователей с худшей сетью — то есть там, где её труднее всего диагностировать.

Вместо вывода

Постквантовые алгоритмы уже входят в TLS, но обмен ключами оказался более простой частью перехода. Аутентификация тянет за собой сертификаты, цепочки доверия, OCSP, Certificate Transparency и несколько подписей. У ML-DSA каждая из них измеряется килобайтами.

Как только серверная часть рукопожатия пересекает порядок 14–15 КБ, криптографическое решение становится сетевой проблемой. TCP может потребовать ещё один обмен подтверждениями. QUIC может остановиться у антиамплификационного лимита. Потери затрагивают больше пакетов, а старые промежуточные устройства получают формат и объём, которых раньше не видели.

Сеть не придётся перекраивать с нуля. Но переход не состоится, если криптографы выберут алгоритм, разработчики добавят его в библиотеку, а сетевые инженеры узнают о новых размерах уже из графиков задержек в продакшне.