Тема постквантовой криптографии (PQC) из академической сферы шагнула в практику: крупные браузеры и CDN провели многомесячные A/B‑включения гибридных ключевых обменов, а в софте для TLS уже есть первые стабильные реализации KEM на основе Kyber. Для веба в 2025 году актуален именно гибридный подход: классическая эллиптическая кривая X25519 в связке с постквантовым KEM Kyber768. Такая комбинация уменьшает риски от ретроактивной дешифровки трафика в будущем, сохраняя совместимость с текущей экосистемой.
Зачем веб‑инфраструктуре post‑quantum прямо сейчас
Даже если массовые квантовые компьютеры ещё не пришли, угроза ретроархивирования реальна: трафик можно перехватывать и хранить сегодня, чтобы дешифровать его через годы. Гибридный KEM в TLS 1.3 решает эту проблему в момент рукопожатия: секретный материал формируется двумя механизмами — классическим (X25519) и постквантовым (Kyber). Для атакующего это две независимые задачи: взломать кривую и взломать Kyber. Пока обе не скомпрометированы одновременно, трафик остаётся защищённым.
Практические причины готовиться уже в 2025:
- Ожидаемая стандартизация и зрелость реализаций Kyber (ML‑KEM) на уровне библиотек TLS.
- Сложившаяся практика гибридных групп X25519+Kyber768 в браузерах/QUIC‑стеках.
- Низкие накладные расходы по CPU и умеренный рост размера рукопожатия.
- Совместимость: старые клиенты продолжат использовать X25519 без падений соединений.
Коротко про термины: KEM, Kyber, ML‑KEM, гибрид
KEM (Key Encapsulation Mechanism) — механизм, позволяющий договориться о секрете без прямого обмена им, похожий по роли на ECDH в TLS. Kyber — семейство постквантовых KEM, выбранное NIST; в окончательной терминологии NIST — ML‑KEM, но в индустрии по инерции используется «Kyber». Обычно для веба рассматривают уровень безопасности Kyber768 (сбалансирован по размеру и стойкости).
Гибридный KEM — когда в одном рукопожатии одновременно используются X25519 и Kyber768. Ключевой материал получается комбинированием двух независимых секретов. Цель — защита от будущих квантовых атак при сохранении текущей интероперабельности.
Как это стыкуется с TLS 1.3, ALPN, HTTP/2 и HTTP/3
Гибридный KEM — это про группы (key share) в TLS 1.3, а не про шифросюиты. Клиент в ClientHello объявляет поддерживаемые группы, сервер выбирает одну. Для гибридного варианта используется именованная группа вроде «X25519Kyber768» (название зависит от реализации библиотеки TLS).
Важные детали:
- ALPN (например, h2, http/1.1, h3) не зависит от KEM. Наличие гибридной группы не ломает выбор протокола уровня приложения.
- HTTP/3 (QUIC) использует TLS 1.3 для криптографии. Рост ClientHello/ServerHello при включении Kyber может быть заметен, но современные QUIC‑стеки и сети это переваривают. Следите за MTU и фрагментацией UDP.
- Сеансы и 0‑RTT в TLS 1.3/QUIC продолжают работать; способ генерации трафикового секрета меняется, но не поведение API.
Если у вас терминация QUIC на балансировщике, пригодится разбор по теме: терминация HTTP/3 и QUIC в HAProxy.
Накладные расходы: сколько байт и CPU
Kyber768 добавляет сотни байт к сообщениям рукопожатия: публичный ключ порядка килобайта и шифротекст аналогичного масштаба. В гибридном режиме всё это едет вместе с X25519. Типичный рост первой пары сообщений — около 2–3 КБ по проводу (в зависимости от формата реализации). На CPU накладка умеренная: Kyber разработан с расчётом на высокую производительность на обычных серверах.
Где это может ощущаться:
- Высокая доля cold‑handshake соединений с краткими сессиями и без резюмпции.
- Малые MTU/жёсткие UDP‑ограничения в экзотических сетях для HTTP/3.
- Очень чувствительные к латентности API‑эндпоинты с большим количеством новых подключений в секунду.
Совместимость: что будет со старыми клиентами
Классические клиенты, не знающие про Kyber, просто не предложат гибридные группы, и сервер выберет X25519. Включённый на сервере гибрид не отключает X25519; вы управляете приоритетом групп. Критически важно не вырубать классические группы преждевременно, пока парк клиентов не обновится.
Сертификаты и подписи: при чём здесь SSL
KEM относится к обмену ключами, а не к механизмам подписи серверного сертификата. В веб‑PKI в 2025 всё ещё доминируют RSA и ECDSA. Практически: используйте ECDSA P‑256 (и при необходимости параллельно RSA) — это не конфликтует с гибридным KEM. Постквантовые подписи (например, Dilithium) для публичного веба ещё проходят путь массовой поддержки, поэтому фокус сейчас — именно гибридный KEM для рукопожатия. При этом действующие SSL-сертификаты менять не нужно.
Полезно совместно обновлять политику HSTS и порядок миграции домена; см. материал: миграция домена, 301, HSTS и SSL.
Где это уже работает: библиотеки и стеки
Реализация гибридных групп зависит от библиотеки TLS. В 2025 наиболее заметна поддержка в QUIC‑стеках на базе BoringSSL, а также в сборках OpenSSL с постквантовыми провайдерами. Нюансы:
- Названия групп отличаются. Встречаются варианты вроде «X25519Kyber768», «X25519+Kyber768», «P256_KYBER768» и т. п.
- В ванильном OpenSSL без постквантового провайдера гибридных групп может не быть. Нужны сборки с поддержкой Kyber.
- Apache привязан к OpenSSL; Nginx можно собирать с разными криптобиблиотеками, в том числе BoringSSL (особенно для HTTP/3).
Как тестировать клиента: быстрый чек
Проверить, поддерживает ли ваш клиент гибрид, можно утилитами библиотек.
Примеры с bssl (BoringSSL)
bssl client -connect example.com:443 -alpn h2 -groups X25519Kyber768
bssl client -connect example.com:443 -alpn h3 -groups X25519Kyber768
bssl client -connect example.com:443 -tls13 -groups X25519Kyber768,X25519 -debugОбратите внимание на выбранную группу в выводе. Если сервер не поддерживает гибрид, будет выбран X25519.
Примеры с openssl s_client (при наличии PQ‑сборки)
openssl s_client -connect example.com:443 -tls1_3 -groups X25519Kyber768
openssl s_client -connect example.com:443 -tls1_3 -alpn h2 -groups X25519Kyber768:X25519
openssl s_client -connect example.com:443 -tls1_3 -msg -stateЕсли ваша сборка не знает «X25519Kyber768», команда выдаст ошибку. В таком случае проверьте, какие группы доступны в вашей библиотеке, и используйте корректное имя.
Nginx: приоритизация групп и логирование
В Nginx для TLS 1.3 выбор групп задаётся директивой ssl_ecdh_curve (да, исторически «ecdh», но она применима и к named groups TLS 1.3). Для сборок с поддержкой гибридной группы настройка может выглядеть так:
ssl_protocols TLSv1.3;
ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;
ssl_ecdh_curve X25519Kyber768:X25519:secp256r1;
ssl_prefer_server_ciphers off; # В TLS 1.3 у клиента приоритет по группам, но сервер может ограничить списокЧтобы наблюдать, что реально выбралось на рукопожатии, добавьте в лог формат с переменной $ssl_curve и отметками про протокол/ALPN:
log_format tls '... proto=$ssl_protocol cipher=$ssl_ciphers group=$ssl_curve alpn=$ssl_alpn';
access_log /var/log/nginx/access_tls.log tls;Apache httpd: выбор групп через OpenSSLConf
В Apache используется SSLOpenSSLConfCmd для настройки групп. Конкретные имена зависят от вашей сборки OpenSSL:
SSLEngine on
SSLProtocol TLSv1.3
SSLCipherSuite TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
SSLOpenSSLConfCmd Curves X25519Kyber768:X25519:P-256
Если ваша библиотека не знает X25519Kyber768, Apache не запустится или проигнорирует параметр. Проверьте доступные группы командой вашей библиотеки или документацией к сборке.
HTTP/3 и QUIC: про MTU и Initial
QUIC требует, чтобы первый пакет помещался в минимальный размер Initial. Гибридный KEM увеличивает ClientHello и ServerHello, но современные реализации используют фрагментацию Initial в несколько UDP‑датаграм. Риски возникают в сетях с агрессивной фильтрацией или неправильным PMTUD. Практические рекомендации:
- Следите за ошибками рукопожатия QUIC в метриках и логах.
- Держите включённым HTTP/2 на TCP как запасной план для клиентов с проблемным UDP.
- Убедитесь, что балансировщики/файрволы не триммингуют большие UDP‑пакеты.
План внедрения без сюрпризов
- Инвентаризация TLS‑терминаторов. Где завершается TLS: Nginx/Apache, CDN, L7‑балансировщики, gRPC/Envoy, почтовые сервисы, внутренние API на Ingress.
- Лаборатория. Поднимите стенд с библиотекой, поддерживающей X25519+Kyber768. Прогоните кастомные клиенты (bssl/openssl), curl, браузеры, мобильные SDK. Для быстрого стенда удобно использовать VDS.
- Наблюдаемость. Включите логирование выбранной группы и ALPN. Добавьте алерты на рост рукопожатных ошибок.
- Канареечный запуск. Включите гибрид сначала на отдельном VIP/порту, домене или для малой доли трафика.
- Анализ. Смотрите распределение по
$ssl_curve, время рукопожатия p95/p99, процент QUIC‑ошибок, ретраи соединений. - Расширение охвата. По итогам нескольких дней без регрессий распространяйте на остальной периметр.
Диагностика: на что смотреть при проблемах
- Handshake failure: неизвестные группы для клиента или мидлбокса по пути. Решение — держать X25519 в списке, не заставлять только гибрид.
- Сбои HTTP/3: проверьте размер Initial, ошибку в трассировке QUIC, попытайтесь воспроизвести TCP‑путём (HTTP/2) — если TCP ок, смотрите на UDP‑политику.
- Рост латентности: посчитайте долю cold‑handshake. Включите/настройте резюмпцию, session tickets, TLS session cache.
- Утилизация CPU: профилируйте только на рукопожатиях; обычно Kyber даёт небольшой добавочный график по сравнению с ECDH.
Политики шифров и версий TLS
Гибридный KEM относится к TLS 1.3. Оставляйте TLS 1.2 для обратной совместимости, если у вас есть значимая доля старых клиентов. Шифросюиты TLS 1.3 оставьте стандартными GCM/CHACHA наборами. Пример нейтральной политики:
# TLS 1.3 only для стенда/канареек
ssl_protocols TLSv1.3;
ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;
ssl_ecdh_curve X25519Kyber768:X25519:secp256r1;
# Боевое смешение (1.2 + 1.3) при необходимости
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;
Логирование и метрики: как понять, что гибрид реально работает
Убедиться, что клиенты выбирают гибридную группу, можно несколькими способами:
- Логи веб‑сервера: переменная
$ssl_curveв Nginx, аналогичные поля в других фронтах. - Трассировка клиента: bssl/openssl выводят выбранную группу.
- Сниффинг в разрешённых средах (например, на стенде): размер ClientHello/ServerHello заметно растёт.
Частые вопросы
Нужно ли менять сертификаты?
Нет. Сертификаты и подписи — это отдельный слой. Используйте ECDSA P‑256 (и при необходимости RSA) как раньше. KEM затрагивает только обмен ключами в рукопожатии TLS 1.3. При необходимости продлить или выпустить новые — доступны SSL-сертификаты.
Поменяется ли ALPN или поддержка HTTP/2/HTTP/3?
Нет. ALPN независим от KEM. Поддержка h2/h3 сохраняется. Единственное, что меняется — объём рукопожатия и немного CPU.
Какие имена у гибридных групп?
Зависят от библиотеки: «X25519Kyber768», «X25519+Kyber768», «P256_KYBER768» и т. п. Смотрите документацию вашей сборки. Если сервер не стартует с незнакомой группой — проверьте поддержку на уровне TLS‑библиотеки.
Можно ли выключить классические группы и оставить только Kyber?
В 2025 это преждевременно: вы потеряете клиентов. Рекомендуется гибрид + классические группы для совместимости.
Какой уровень Kyber выбирать?
Kyber768 — сбалансированный выбор для веба. Более низкий уменьшит размер, более высокий увеличит его без очевидной пользы для большинства сценариев.
Контрольный чек‑лист перед включением
- Есть стенд с поддержкой X25519+Kyber768; пройдены интеграционные тесты.
- В логах видны выбранные группы; настроены алерты на рост ошибок рукопожатия.
- HTTP/3 включён и проверен в условиях ограниченного MTU; при необходимости настроен fallback на HTTP/2.
- Проведён канареечный запуск и анализ латентности/CPU/байт рукопожатий.
- Обновлены рабочие инструкции для SRE/дежурных: как откатить изменения и где смотреть метрики.
Итоги
Постквантовый TLS через гибридный KEM X25519+Kyber — практичный компромисс между будущей стойкостью и текущей совместимостью. Его можно аккуратно включать уже в 2025, начиная с периметра с низким риском и хорошей наблюдаемостью. План внедрения прост: подготовка стенда, приоритизация групп, канареечный запуск, метрики и постепенное расширение охвата. При этом вы ничего не меняете в сертификатах, не ломаете ALPN и сохраняете привычную производственную эксплуатацию.
Главная мысль: добавьте гибридный KEM в арсенал, но не выключайте классические группы. Это даст защиту «на будущее» без потерь пользователей «сегодня».
Если у вас сложная топология с несколькими TLS‑терминаторами, начните с самого внешнего слоя и заранее согласуйте, как логировать выбранные группы и разграничивать TCP/QUIC трафик. Так вы быстрее поймёте реальный эффект от включения гибридного KEM и не встретите неожиданностей. Для проектов на нашем виртуальном хостинге и на VDS рекомендации одинаковы: сначала стенд, потом канарейка, затем постепенное расширение.
