Постквантовый TLS на nginx: стоимость рукопожатия
Стоимость рукопожатия в постквантовом TLS на nginx складывается из CPU криптографии, объёма обмена и сети. Результат для ML-KEM TLS на nginx верен только для заданных версий ПО, группы, клиента, RTT, MTU и resumption.
Сколько задержки добавляет гибридный постквантовый TLS?
Гибридный обмен добавляет ML-KEM и увеличивает сообщения TLS, поэтому прибавка зависит от стенда. В локальной сети большую долю задержки может дать CPU, а при высоком RTT и потерях сильнее влияет сеть. Разницу показывают парные cold-прогоны с одной группой, cipher suite, RTT и MTU.
Классический, постквантовый и гибридный обмен без терминологической путаницы
X25519MLKEM768 сочетает X25519 и ML-KEM-768. Подпись и симметричный шифр остаются классическими, и свойства ML-KEM на них не переносятся. Поле negotiated group подтверждает ML-KEM TLS на nginx, а отчёт указывает классическую часть и алгоритм подписи.
Версии, provider и совместимость nginx с клиентами
Набор групп задают TLS-библиотека и provider, поэтому в отчёт идут nginx -V, версия libcrypto и флаги сборки. Бенчмарк постквантового TLS проводят после согласования с целевыми клиентами:
nginx -V openssl list -tls1_3 -tls-groups openssl s_client -connect HOST:443 -servername HOST -groups X25519MLKEM768 -brief
Старые реализации с draft code points идут отдельной серией.
Где появляются дополнительные вычисления и байты
В полном handshake клиент отправляет ML-KEM key share, а сервер инкапсулирует секрет. Для X25519MLKEM768 shares клиента и сервера составляют 1216 и 1120 байт. Задержка гибридного TLS-рукопожатия зависит от MTU и retransmissions.
Убирает ли session resumption основную часть расходов?
Session resumption убирает передачу сертификата, но эфемерный обмен может остаться. В TLS 1.3 psk_dhe_ke снова выполняет эфемерный обмен, psk_ke его пропускает и не добавляет новой прямой секретности. Cold и resumed handshakes проверяют раздельно, фиксируя pcap, negotiated mode, CPU и факт возобновления.
Классика, гибрид, холодный старт и resumption
X25519 и X25519MLKEM768 сравнивают при одинаковых cipher suite, цепочке сертификатов и nginx.conf, разделяя cold и resumed-серии. Производительность PQC на nginx показывают CPU-замеры и pcap, а RFC 10024 задаёт размеры shares для сверки. tc netem меняет RTT, потери проверяют отдельно.
Cycles, насыщение ядер и предел новых соединений
Стоимость ML-KEM в TLS 1.3 считают как разницу cycles и CPU time между гибридом и контролем, делённую на число cold handshakes. Нагрузку поднимают до плато, записывая CPU, %steal, ошибки accept и listen queue.
Размер обмена, RTT и чувствительность к потерям
Pcap даёт байты по направлениям, TLS records, пакеты и retransmissions. Одинаковая certificate chain отделяет цену key share от сертификата. Wall latency сопоставляют с RTT, серию с потерями держат отдельно.
Какие метрики nginx и TLS нужно измерять?
1. CPU cycles и CPU time на успешный cold и resumed handshake.
2. Wall latency p50/p95/p99, negotiation errors и новые соединения в секунду.
3. Байты, TLS records, пакеты, retransmissions и negotiated group.
Reuse, session resumption и защита от handshake-флуда
Keep-alive сокращает число новых соединений. Конфигурация задаёт session cache, а лог и метрики подтверждают PSK и hit rate. Rate limit и CPU-резерв считают по числу новых соединений. Reuse помогает против честного трафика, но атакующий открывает новые соединения, и каждое стоит полного обмена.
Совместимость, canary и наблюдаемые критерии отката
Долю поддерживающих клиентов и поведение fallback проверяют до canary. В мониторинге раздельно видны negotiation errors, p95/p99, CPU и resumption rate. Requests per second для полных рукопожатий считают отдельно от HTTP RPS. Выход за SLO или CPU-бюджет означает откат.
Стоимость рукопожатия в постквантовом TLS на nginx приемлема, если клиенты согласуют стандартную группу, серии укладываются в SLO при заданных RTT и MTU, а CPU сохраняет запас. Иначе canary сужают или остаются на классической группе.
