Введение

Постквантовая криптография (PQC) из «темы на будущее» перешла в плоскость эксплуатационных задач: стандарты утверждены, реализации появились в массовых библиотеках, а риск «собрали трафик сегодня — расшифровали завтра» (harvest now, decrypt later) делает откладывание дорогим именно для данных с долгим сроком ценности. На уровне базовых криптопримитивов уже есть финализированные стандарты для обмена ключами (ML‑KEM) и цифровых подписей (ML‑DSA, SLH‑DSA), и регулятор прямо подталкивает админов и инженеров начинать переход как можно раньше. 

На практике миграция TLS/SSH в 2026 году — это почти всегда гибридный сценарий: вы добавляете постквантовый компонент к существующему ECDHE/X25519‑обмену ключами (в TLS и SSH), сохраняя совместимость и имея понятный откат. Так вы закрываете именно «долгосрочную конфиденциальность» уже сейчас, не ломая публичную PKI и экосистему клиентов. 

Дальше в статье — практическая и пошаговая дорожная карта для сервиса и клиентов: инвентаризация, тестирование, включение гибридных групп/алгоритмов, мониторинг переговоренных параметров, rollout/rollback, а также нюансы производительности, совместимости и PKI.

Почему PQC нужно планировать уже сейчас

Что именно «ломает квант»

Если говорить максимально прикладно для эксплуатационщиков, основной удар квантовых атак приходится по публично‑ключевой криптографии, на которой держатся:

• обмен ключами (Diffie‑Hellman / ECDH / X25519) — то, что обеспечивает PFS и шифрование трафика в TLS/SSH;
• подписи (RSA/ECDSA/EdDSA) — то, что обеспечивает аутентичность сертификатов, SSH‑ключей, обновлений и артефактов.

Поэтому наиболее быстрый практический выигрыш даёт перенос именно обмена ключами на гибридные/постквантовые схемы в TLS 1.3 и SSH KEX.

Позиция NIST и временные ориентиры

Критично, что это не «исследовательская рекомендация», а курс на уровне стандартов и планов перехода:

• NIST выпустил первые три финализированных PQC‑стандарта и прямо призывает системных администраторов начинать переход как можно скорее. 
• На странице проекта PQC NIST подчёркивает: с выходом первых стандартов организациям следует начинать миграцию, а по переходному таймлайну NIST планирует депрецировать и затем убрать квант‑уязвимые алгоритмы из стандартов к 2035 году, причём «высокорисковые системы» должны переходить заметно раньше. 
• NIST IR 8547 (публичный драфт) описывает ожидаемый подход к переходу и должен использоваться как «рамка» для планирования в индустрии и госсекторе. 

Практический вывод для эксплуатации: если у вас есть данные с жизненным циклом 5–10+ лет (персональные данные, финансы, коммерческие тайны, межсервисные токены/ключи, резервные копии), то TLS/SSH‑миграцию на гибридный режим разумно включать в дорожные карты уже сейчас, а не «к 2030».

Стандарты и алгоритмы PQC, которые важно знать для TLS и SSH

Ниже — минимальный «словарик» без академической нагрузки, но с теми числами и свойствами, которые реально влияют на MTU, latency и PKI.

Состояние PQC‑стандартов NIST на апрель 2026

NIST в августе 2024 выпустил три основных PQC‑стандарта (FIPS), которые «готовы к немедленному использованию» и составляют основу большинства внедрений: ML‑KEM (обмен ключами), ML‑DSA и SLH‑DSA (подписи). 

Параллельно продолжается стандартизация дополнительных алгоритмов: NIST прямо указывает, что помимо трёх «первых» алгоритмов выбраны для дальнейшей стандартизации подпись Falcon (будущий FN‑DSA) и KEM HQC. 

Почему гибрид почти всегда лучше «чистого PQ» в транспортных протоколах

Для TLS/SSH в реальной прод‑эксплуатации чаще всего выбирают гибридный обмен ключами:

• он сохраняет безопасность, даже если позже в PQ‑схеме найдут уязвимость (остаётся классический компонент);
• он смягчает риски несовместимости и «сырости» реализаций;
• он позволяет работать с публичной PKI без немедленного перехода на PQ‑подписи в сертификатах.

Именно поэтому массовые стеки в 2025–2026 годах активно двигаются через гибридные группы вида X25519MLKEM768 (TLS) и mlkem768x25519‑sha256 (SSH). 

Таблица сравнения: что меняется в размерах ключей/сообщений

Эта таблица даёт понимание, почему «PQC = больше байт на рукопожатие», и где это может ударить по сетевым траекториям, балансерам и DPI.

Ключевой эксплуатационный вывод: для TLS/SSH сначала проще и выгоднее включить ML‑KEM‑768 в гибриде (это влияет на размеры ClientHello/ServerHello key_share, но не требует менять сертификаты), а миграцию подписей и PKI делать отдельным этапом.

Реализации на сегодня: OpenSSL, OpenSSH, LibreSSL и популярные серверы/клиенты

TLS: OpenSSL 3.5 как «точка сборки» PQC в массовом Linux

OpenSSL 3.5 — важный рубеж, потому что в нём появились:

• поддержка PQC‑примитивов (ML‑KEM и ML‑DSA в официальной ветке) и
• поддержка гибридных TLS‑групп для key exchange: X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024. 

При этом документация OpenSSL отдельно подчёркивает практический компромисс: CPU‑стоимость близка к соответствующим ECDH‑группам, но сообщения обмена ключами существенно крупнее. 

Ещё один практический момент: OpenSSL 3.5 ввёл команды для инвентаризации групп, что сильно упрощает диагностику «что вообще доступно в этой сборке»:

openssl list -tls-groupsopenssl list -all-tls-groups

Это упоминается в обсуждении/issue по добавлению команды в OpenSSL 3.5. 

Важная деталь по дефолтам. В OpenSSL 3.5 гибрид X25519MLKEM768 поставлен первым в дефолтном списке групп, и клиенты обычно шлют его как приоритетный key share. Это отлично для раннего перехода, но может всплыть на «хрупких» сетевых трактах (старые TLS‑терминаторы, DPI, некоторые L7‑прокси), где большие ClientHello вызывают проблемы. Поэтому стратегия миграции ниже всегда включает canary + мониторинг + план отката.

TLS: NGINX/Apache/HAProxy — PQC появляется «автоматом», если библиотека умеет

Большинство популярных серверов и прокси не «реализуют PQC» сами — они используют TLS‑библиотеку:

• NGINX: выбор групп делается директивой ssl_ecdh_curve, которая задаёт список поддерживаемых кривых/групп при использовании OpenSSL. С OpenSSL 3.5 в этот список уже можно включать гибридные группы (например, X25519MLKEM768), и это становится практической конфигурационной ручкой.
• Apache httpd (mod_ssl): можно явно задавать группы через SSLOpenSSLConfCmd Groups ... (это прокидывается в OpenSSL). Пример ниже.
• HAProxy: управляет группами через настройки «curves» (глобальные defaults или per‑bind), опираясь на возможности используемой SSL‑библиотеки. Практически важный вывод: PQC в HAProxy появляется, когда HAProxy собран с OpenSSL 3.5 и вы включили соответствующие группы.

SSH: OpenSSH уже живёт в «гибридной эпохе»

Для SSH ситуация часто даже проще, чем для TLS, потому что OpenSSH уже несколько релизов делает гибридный KEX дефолтом:

• OpenSSH внедрил гибридный sntrup761x25519‑sha512@openssh.com и сделал его приоритетным/дефолтным в современных сборках. 
• По состоянию на OpenSSH 10.x введён гибридный mlkem768x25519‑sha256, и он становится «первым выбором» в новых релизах. 
• Начиная с OpenSSH 10.1 добавлено предупреждение, если соединение устанавливается без постквантового KEX. 

Это означает: во многих Linux‑дистрибутивах вы «почти уже мигрировали» на уровне KEX, если поддерживаете актуальные версии OpenSSH на клиентах и серверах.

LibreSSL: осторожно с ожиданиями «в релизе» vs «в разработке»

LibreSSL активно двигается, но важно различать:

• в стабильных релизах появились элементы, необходимые для ML‑KEM (например, публичный API); 
• поддержка MLKEM768_X25519 keyshare в TLS (и сопутствующие изменения) фигурирует в changelog ветки «in development» (например, 4.3.0). 

Для прод‑планирования это значит: если ваша инфраструктура сильно завязана на LibreSSL, закладывайте дополнительные проверки по конкретным версиям и backport‑политике в вашем дистрибутиве.

Таблица: где реально доступен PQC‑обмен ключами «из коробки»

Дорожная карта миграции TLS для сервиса и клиентов

Ниже — практический план (без предположений о ваших конкретных SLA/регуляторике: если детали не заданы, считаем их неуточнёнными). Логика такая: сначала гибридный KEX, затем — по готовности экосистемы — подписи/сертификаты.

Таймлайн миграции (ориентир)

timeline    title PQC миграция TLS (ориентир для прод-эксплуатации)    section Подготовка      Инвентаризация TLS-терминации/клиентов : 0-4 недели      Классификация сервисов по критичности и сроку ценности данных : 0-6 недель    section Лаборатория      Сборка/подключение OpenSSL 3.5 на стенде : 2-8 недель      Тесты совместимости (клиенты, LB, WAF, прокси) : 4-10 недель      Нагрузочные тесты и MTU/fragmentation проверки : 6-12 недель    section Пилот      Canary на 1-5% трафика (гибридный KEX) : 8-16 недель      Наблюдаемость: метрики, логи negotiated group, ошибки рукопожатия : 8-20 недель    section Масштабирование      Rollout на Tier-1 сервисы (интернет/межсервисы) : 4-9 месяцев      Стандартизация baseline (policy, CI checks) : 6-12 месяцев    section Эволюция      Подготовка к PQ-подписям в PKI (внутренние mTLS контуры) : 9-24 месяцев      Переоценка после обновлений стандартов/реализаций : ежегодно

Ориентир по «глобальным дедлайнам» даёт NIST: движение идёт к депрецированию и удалению квант‑уязвимых алгоритмов к 2035, а «высокорисковые» должны мигрировать раньше. 

Этап планирования: инвентаризация и приоритизация

В реальном проде TLS‑миграция начинает ломаться не на криптографии, а на «зоопарке» точек терминации и клиентов. Поэтому цель инвентаризации — получить список:

• где вы терминируете TLS (edge LB/CDN, ingress, service mesh, прямой NGINX/Apache, gRPC‑балансеры);
• какие TLS‑библиотеки реально используются на серверах и клиентах (OpenSSL/GnuTLS/BoringSSL/LibreSSL/Go crypto/tls/JSSE и т.д.);
• какие узлы ограничены FIPS‑режимом или HSM‑политиками;
• какие сегменты сети потенциально «хрупкие» (DPI, старые WAF, прокси, устройства).

Практическая приоритизация по критичности:

• Tier‑0/Tier‑1: внешние веб‑эндпоинты, API, SSO, платежи, внутренний mTLS между критичными сервисами; данные с долгой ценностью.
• Tier‑2: админ‑панели, служебные API, батч‑каналы.
• Tier‑3: вторичные сервисы, где риск HNDL ниже (например, короткоживущие данные и низкая ценность).

Этап лаборатории: «включаем PQC так, чтобы можно было выключить»

Базовый принцип: не трогаем сертификаты на первом шаге

Гибридный/постквантовый обмен ключами в TLS 1.3 можно включить, не меняя сертификаты сервера (сертификаты продолжают быть RSA/ECDSA/Ed25519). Это важное упрощение, потому что публичная экосистема X.509 будет догонять PQ‑подписи заметно дольше.

Отдельно отмечается, что гибрид X25519MLKEM768 в OpenSSL — «TLS‑only примитив» (не универсальный KEM для всех протоколов), что ещё раз подчёркивает: в TLS это решается на уровне групп/key share, а не через «переезд сертификатов за один релиз». 

Проверяем, что OpenSSL 3.5 действительно привнесён и активен

Минимальный набор команд для стенда:

# Версия и директория конфиговopenssl version -aopenssl version -d# Какие TLS-группы доступныopenssl list -tls-groupsopenssl list -all-tls-groups

Команды -tls-groups/-all-tls-groups привязаны к OpenSSL 3.5. 

Управление группами: миссия критична для совместимости и rollback

В OpenSSL можно управлять поддерживаемыми группами и тем, какие key shares посылает клиент (в TLS 1.3), через «group list» (в документации это описано в терминах SSL_CTX_set1_curves_list/SSL_CTX_set1_groups_list и др.). Важные эксплуатационные детали:

• можно ссылаться на встроенный список как DEFAULT;
• можно удалять группу из дефолта (например, DEFAULT:-X25519MLKEM768);
• можно указывать предсказанные key shares звёздочкой * (сервер игнорирует *, клиент — нет);
• можно игнорировать неизвестные группы префиксом ? (полезно для «один конфиг на разные сборки»). 

Это — базовый механизм вашего безопасного rollout/rollback.

Развёртывание на стороне сервиса: практические конфиги

Ниже примеры для Linux. Пути могут отличаться по дистрибутивам; если у вас не указан дистро, принимайте это как шаблоны.

Вариант A: NGINX (TLS‑терминация на nginx, library = OpenSSL 3.5)

Файл: /etc/nginx/nginx.conf или /etc/nginx/conf.d/site.conf

server {    listen 443 ssl http2;    server_name example.com;    ssl_certificate     /etc/ssl/certs/example.com.fullchain.pem;    ssl_certificate_key /etc/ssl/private/example.com.key;    # Базовый минимум: TLS 1.2+ (TLS 1.3 предпочтителен для KEX-групп)    ssl_protocols TLSv1.2 TLSv1.3;    # Важно: список групп/кривых для (EC)DHE и TLS 1.3 supported_groups.    # При наличии OpenSSL 3.5 сюда можно добавить гибрид X25519MLKEM768.    #    # Стратегия "безопасный старт": гибрид + fallback на X25519/P-256    ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;    # Для наблюдаемости удобно логировать negotiated group и предложенные группы.    # NGINX предоставляет $ssl_curve / $ssl_curves (в зав-ти от версии); смотрите ниже log_format.    access_log /var/log/nginx/access.log main;}

Директива ssl_ecdh_curve официально задаёт список поддерживаемых кривых при использовании OpenSSL. Переменные $ssl_curve и $ssl_curves существуют в NGINX и позволяют логировать negotiated group/список групп. 

Пример log_format (в http{} блока):

log_format main '$remote_addr - $host [$time_local] '                '"$request" $status $body_bytes_sent '                'tls=$ssl_protocol cipher=$ssl_cipher '                'group=$ssl_curve groups=$ssl_curves '                'rt=$request_time';

Нюанс: в некоторых комбинациях NGINX/OpenSSL новые PQC‑группы могли логироваться не «красивым» именем, а в hex, из‑за способа сопоставления групп. Для этого в истории изменений NGINX есть отдельные обсуждения/фиксы, ставшие заметнее после добавления X25519MLKEM768 в дефолт OpenSSL 3.5. 

Вариант B: Apache httpd (mod_ssl)

Файл: обычно /etc/apache2/sites-enabled/000-default-le-ssl.conf (Debian/Ubuntu) или /etc/httpd/conf.d/ssl.conf (RHEL‑семейство)

<VirtualHost *:443>    ServerName example.com    SSLEngine on    SSLCertificateFile      /etc/ssl/certs/example.com.fullchain.pem    SSLCertificateKeyFile   /etc/ssl/private/example.com.key    SSLProtocol             -all +TLSv1.2 +TLSv1.3    # Ключевое: управление группами через OpenSSLConfCmd (пробрасывается в libssl).    # Список: гибрид + классические fallback.    SSLOpenSSLConfCmd Groups "X25519MLKEM768:X25519:prime256v1"</VirtualHost>

Эта схема использует механизм настройки TLS‑групп в OpenSSL (через конфиг‑команды). Важно, что сами названия групп берутся из реализации OpenSSL 3.5, где X25519MLKEM768 определён как гибридная группа. 

Вариант C: HAProxy (TLS‑терминация на HAProxy)

Файл: /etc/haproxy/haproxy.cfg

global    log /dev/log local0    maxconn 50000    # Рекомендуется включить capture cipherlist для диагностики совместимости    tune.ssl.capture-cipherlist-size 800defaults    mode http    log global    option httplog    timeout connect 5s    timeout client  60s    timeout server  60sfrontend fe_https    bind :443 ssl crt /etc/haproxy/certs/example.com.pem alpn h2,http/1.1    # Зависит от версии HAProxy и SSL-библиотеки: задаём приоритет групп (curves).    # Идея та же: гибрид + fallback.    # (Синтаксис может отличаться по версиям; проверяйте `haproxy -vv` и вашу документацию.)    # ssl-default-bind-curves X25519MLKEM768:X25519:prime256v1    # Логи: добавляем версию TLS и cipherlist (полезно при «вдруг отвалились старые клиенты»)    log-format "%ci:%cp [%tr] %ft %b/%s %ST %B tls=%sslv c=%sslc %[ssl_fc_cipherlist_str]"    default_backend be_app

Шаблон лог‑формата с %sslv, %sslc и ssl_fc_cipherlist_str, а также необходимость tune.ssl.capture-cipherlist-size, полезны для расследований TLS‑ошибок и оценки совместимости. 

Этап rollout: canary, постепенность, контроль «что реально договорилось»

Поток развёртывания (рекомендуемый)

flowchart TD    A[Стенд: OpenSSL 3.5 + гибридные группы] --> B[Тесты совместимости: клиенты/прокси/WAF]    B --> C{Ошибки рукопожатия\n> базового порога?}    C -- Да --> R[Сужаем группы:\nоставляем X25519,\nоткатываем PQ]\n    C -- Нет --> D[Canary 1-5% трафика]    D --> E[Мониторинг: handshake failures,\nтайминги, negotiated group,\nClientHello size]    E --> F{SLO в норме\nи нет всплеска ошибок?}    F -- Нет --> R2[Rollback: убрать X25519MLKEM768\nиз group list]    F -- Да --> G[Rollout 25% -> 50% -> 100%]    G --> H[Закрепляем baseline:\npolicy+CI checks+runbooks]

Как делать rollback «в одну ручку»

Rollback должен быть банальным: убрать PQC‑группу из списка.

Если вы управляете группами через OpenSSL‑механизм, полезно знать, что можно начинать от DEFAULT и исключать X25519MLKEM768 (или любую другую группу) из дефолта. Это прямо предусмотрено синтаксисом списка групп. 

Пример в стиле OpenSSL group list (концептуально):

• было: Groups = DEFAULT
• стало: Groups = DEFAULT:-X25519MLKEM768

Плюс можно сохранить в конфиге «мягкий режим» через ?‑префикс, чтобы конфиг не ломался на хостах без нужной группы. 

Дорожная карта для клиентов TLS

С клиентами всё зависит от того, кто ваш клиент.

Если ваши клиенты — «общественный интернет» (браузеры/мобильные приложения)

Обычно вы не можете заставить всех клиентов поддерживать PQC. Поэтому стратегия:

1) включаете PQC‑гибрид на сервере; 2) удостоверяетесь, что клиенты, которые умеют, договариваются о гибриде, а остальные — уходят в X25519/P‑256 без падения; 3) мониторите handshake failures и negotiated group.

Cloudflare ведёт справочную страницу по поддержке гибридных PQ‑соглашений разными софтами — полезная точка сверки для «кто уже умеет». 

Если ваши клиенты — контролируемые агенты/SDK (DevOps‑сценарии)

Тогда вы можете ехать быстрее и жёстче.

Go‑клиенты/сервисы. В Go 1.24 гибридный X25519MLKEM768 включён по умолчанию при CurvePreferences == nil, а откат делается через GODEBUG=tlsmlkem=0. 

Практический код‑паттерн для «управляемого отката» (через env):

# Отключить ML-KEM гибрид в Go TLS для быстрой деэскалации инцидентаexport GODEBUG=tlsmlkem=0systemctl restart your-service

Java‑клиенты (OpenJDK/SunJSSE). В рамках внедрения гибридных KEM для TLS (JEP 527) добавляются X25519MLKEM768 и соответствующие группы на NIST‑стандартизированном ML‑KEM, и они включаются по умолчанию при отсутствии явного списка jdk.tls.namedGroups.

Дорожная карта миграции SSH для сервиса и клиентов

Для админов SSH часто «самый дешёвый» способ получить постквантовый выигрыш в транспортном канале: OpenSSH уже сделал большую часть работы.

Базовая стратегия

1) Убедиться, что серверы и клиенты используют актуальный OpenSSH.2) Проверить, какой KEX реально выбирается и не отключён ли PQC‑KEX корпоративными hardening‑политиками.3) При необходимости — зафиксировать KexAlgorithms в конфиге (и оставить fallback).4) Включить наблюдаемость (хотя бы через диагностические команды и выборочный verbose).

OpenSSH документирует текущую PQC‑позицию и то, что в новых версиях приоритет отдан гибридному mlkem…+x25519, а также присутствует предупреждение для не‑PQC соединений. 

Конфигурация на стороне сервера (sshd)

Файл: /etc/ssh/sshd_config

Рекомендуемый подход: фиксируем KEX‑алгоритмы так, чтобы:

• первым шёл постквантовый/гибридный;
• дальше — fallback на curve25519;
• дальше — при необходимости — на более старые группы (если у вас реально есть такие клиенты).

Пример:

# /etc/ssh/sshd_config# Явно задаём KEX приоритет: PQ/hybrid -> modern classical.KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256# Остальные настройки опускаем (аутентификация/ключи — отдельная тема)

Названия гибридных KEX и их приоритеты зависят от версии OpenSSH; в новых релизах присутствует mlkem768x25519‑sha256 и sntrup761x25519‑sha512@openssh.com. 

Применение:

sshd -t && systemctl reload sshd

Конфигурация на стороне клиента

Файл: ~/.ssh/config (пользователь) или /etc/ssh/ssh_config (системная политика)

Host *    KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256

Проверка: что реально выбралось

Диагностика (быстро и надёжно):

# Список KEX, которые умеет текущий клиентssh -Q kex | head# Подробный вывод negotiationssh -vvv user@host

Плюс ориентируйтесь на то, что OpenSSH начиная с 10.1 сигнализирует, если договорились без PQC KEX — это полезно как «охранный датчик», когда политики случайно вырезали нужные алгоритмы. 

PKI, производительность, риски, мониторинг и итоговый чек-лист

PKI и сертификаты: как разделить «конфиденциальность» и «аутентичность»

Реальность 2026: для многих вы сможете включить PQ‑устойчивую конфиденциальность через гибридный KEX (TLS/SSH) заметно раньше, чем сможете заменить аутентификацию (сертификаты/подписи).

Почему:

• менять сертификаты на PQ‑подписи означает менять всю цепочку: CA, политики, клиенты, инспекцию, иногда HSM, и отдельно решать совместимость с публичными корневыми хранилищами;
• гибридный KEX решает именно «harvest now, decrypt later» для трафика без необходимости менять PKI немедленно.

При этом NIST подчёркивает, что ML‑KEM/ML‑DSA/SLH‑DSA «могут и должны» применяться уже сейчас, а стандарты готовы для использования. 

Практическая стратегия PKI по слоям:

• Интернет‑фронты (публичные браузеры): оставить классические сертификаты (ECDSA/RSA) до тех пор, пока экосистема публичной PKI не будет готова; включить гибридный KEX на TLS 1.3.
• Внутренний mTLS (контролируемые клиенты): параллельно подготовить экспериментальный контур с ML‑DSA сертификатами (например, для сервис‑меша/агентов), но запускать только после проверки совместимости клиентов.
• Артефакты/подписи обновлений: отдельный трек, часто быстрее и безопаснее для пилота, чем X.509 для браузеров.

Производительность и «сетевые» эффекты PQC

Увеличение рукопожатия

Даже в гибридном режиме ключевые «байтовые» увеличения идут от ML‑KEM:

• для ML‑KEM‑768 публичный ключ 1184 байта и ciphertext 1088 байт. В гибриде это добавляется к классическому X25519 keyshare и служебным структурам TLS.

OpenSSL прямо предупреждает: CPU‑стоимость сопоставима с ECDH, но сообщения ключевого обмена заметно больше. 

Практические риски от этого: - фрагментация ClientHello/ServerHello и проблемы у старых middlebox; - рост handshake latency на «длинных» сетях и при packet loss; - неожиданные «SSL handshake failure» на некоторых балансерах/прокси.

HelloRetryRequest и лишний RTT

Если клиент не прислал нужный keyshare, сервер может отправить HelloRetryRequest (HRR), что добавляет RTT. Поэтому при внедрении важно, чтобы клиент присылал предсказанные keyshares для самых вероятных групп. OpenSSL поддерживает настройку «predicted keyshares» через * в списке групп, максимум до 4 keyshares. 

Мониторинг и тестирование: что добавить в эксплуатационный контур

TLS: диагностика negotiated group и регрессий

1) Логируйте negotiated group на TLS‑терминации (если это возможно в вашем стеке). В NGINX смотрите $ssl_curve/$ssl_curves. 

2) Собирайте ошибки рукопожатия отдельно от HTTP‑ошибок. Для HAProxy полезно явно расширить log‑format полями TLS и cipherlist, плюс включить tune.ssl.capture-cipherlist-size. 

3) Проверяйте доступные группы и текущие дефолты на каждом целевом образе:

openssl list -tls-groupsopenssl list -all-tls-groups

4) Проверка end‑to‑end рукопожатия (примеры):

# Проверка TLS 1.3 и вывод цепочки сертификатовopenssl s_client -connect example.com:443 -servername example.com -tls1_3 -showcerts# Принудительно задать группы (через конфиг-команды SSL_CONF_cmd; подходит для диагностики)# Синтаксис групп и поддержка описаны в механизме SSL_CTX_set1_curves_list.openssl s_client -connect example.com:443 -servername example.com -tls1_3 -groups X25519MLKEM768:X25519

s_client поддерживает конфиг‑команды SSL_CONF_cmd, а управление/синтаксис списков групп описан в документации OpenSSL. 

SSH: контроль KEX и политика

• Инвентаризация поддерживаемых KEX на клиентах: ssh -Q kex.
• Выборочный ssh -vvv на критичных путях.
• Контроль политик KexAlgorithms в sshd_config и ssh_config.

OpenSSH уже подсвечивает non‑PQC соединения предупреждением в новых версиях — используйте это как сигнал для наблюдаемости и hardening‑регрессий. 

Основные риски и меры смягчения

Таблично — чтобы можно было использовать как «risk register» для change‑management.

Чек‑лист внедрения

Ниже — чек‑лист, который удобно превращать в тикеты. Он намеренно практический.

Подготовка - Зафиксирован список TLS‑точек терминации и используемых TLS‑библиотек по средам/кластерам. - Отдельно отмечены «хрупкие» периметры: WAF/DPI/прокси/старые клиенты. - Определены Tier‑0/Tier‑1 сервисы по критичности и сроку ценности данных.

Стенд - OpenSSL 3.5 (или эквивалентный стек) собран/доставлен на стенд, группы видны через openssl list -tls-groups. - Сервер настроен на гибридную группу + fallback (пример: X25519MLKEM768:X25519:P‑256). - Пройдены тесты: рукопожатие, нагрузка, MTU‑чувствительность, негативные сценарии.

Rollout - Canary включён на малую долю трафика/хостов. - Добавлены метрики/логи negotiated group (NGINX $ssl_curve/$ssl_curves или эквивалент). - Подготовлен rollback: удаление X25519MLKEM768 из списка групп (например, через DEFAULT:-X25519MLKEM768). 

Клиенты - Для контролируемых клиентов (Go/Java) определён policy: включено по умолчанию или gated‑флагом; есть быстрый «выключатель» (например, GODEBUG=tlsmlkem=0 для Go). 

SSH - Проверено, что OpenSSH использует PQ/hybrid KEX (mlkem… или sntrup…); при необходимости KexAlgorithms зафиксирован. 

PKI - Отдельный трек на PQ‑подписи/сертификаты: оценка размера и совместимости (ML‑DSA/SLH‑DSA), пилот в изолированном внутреннем контуре. 

Суть дорожной карты проста: начните с гибридного KEX в TLS и SSH (это даёт выигрыш по «долгой конфиденциальности» уже сейчас), делайте rollout как инфраструктурное изменение уровня «обновление TLS‑библиотеки», держите fallback и быстрый откат, а миграцию PKI на PQ‑подписи планируйте отдельным этапом по зрелости клиентов и внутренних процессов. NIST не просто «разрешает», а прямо подталкивает начинать переход как можно раньше — и это один из редких случаев, когда регуляторская рекомендация хорошо совпадает с эксплуатационной реальностью.