После выхода RFC 10024 в 2026 году: как проверить ML-KEM в TLS 1.3?

RFC 10024 задаёт для TLS 1.3 гибридный обмен ключами, сочетающий ML-KEM и традиционный механизм; включайте его сначала на тестовом контуре и переходите к поэтапному выпуску только после проверки согласованной группы, совместимости и ожидаемого отката. Такой порядок подходит инженерам, которые меняют TLS на клиенте или сервере: запись алгоритма в конфигурации сама по себе не доказывает, что новая группа участвовала в установленном соединении.

Эта инструкция предназначена инженерам, отвечающим за TLS 1.3 и постквантовое тестирование.
Специалисты по выпуску и откату смогут использовать контрольные точки, чтобы оценить риск изменения.
Командам, поддерживающим изолированные стенды, материал поможет оформить повторяемую процедуру испытаний.

Последняя проверка: 1 октября 2026 года; статус стандарта сверён со страницей RFC 10024 в реестре IETF. Поддержку конкретных библиотек, клиентов, серверов и сетевых посредников следует дополнительно сверять с документацией соответствующих разработчиков: публикация стандарта не означает, что реализация уже поставляется включённой по умолчанию.

Этап подготовки: очертить изменение

RFC 10024 определяет гибридный механизм обмена ключами для TLS 1.3. В частности, группа X25519MLKEM768 объединяет традиционный обмен ключами X25519 с ML-KEM-768. Это не означает, что все механизмы TLS уже стали постквантовыми: изменение обмена ключами не переводит автоматически подписи сертификатов, проверку идентичности сервера или прочие криптографические операции на постквантовые алгоритмы. Состав группы и область её применения описаны в тексте RFC 10024, а общие принципы гибридного обмена — в RFC 9954.

Для оценки объёма работ полезно разделить три вопроса. Первый — умеют ли обе стороны предложить и обработать нужную группу. Второй — действительно ли она была согласована в проверяемом соединении. Третий — что произойдёт с трафиком, если посредник, клиент или сервер не поддерживает такой вариант. Положительный ответ только на первый вопрос не является основанием для выпуска.

ML-KEM как алгоритм стандартизован отдельно в FIPS 203 Национального института стандартов и технологий США. TLS 1.3 задаёт протокольный контекст рукопожатия в RFC 8446. Эти документы отвечают на разные вопросы: FIPS 203 определяет алгоритм, RFC 8446 — базовый протокол TLS 1.3, RFC 10024 — способ применить гибридный обмен ключами в этом протоколе. Ни один из них не подтверждает поведение конкретной сборки программного обеспечения.

Перед началом испытаний обозначьте границы проверки: какой входной адрес или сервис тестируется, где завершается TLS, какие клиенты создают соединение и какие посредники стоят на пути. Если TLS завершается на балансировщике, проверка только приложения за ним не отвечает на вопрос о фактической группе соединения. Аналогично, успешный тест между двумя компонентами на стенде не подтверждает совместимость внешних клиентов, чьи реализации и сетевые маршруты отличаются.

Заранее соберите официальные документы именно для применяемых версий TLS-библиотеки, клиента, сервера и балансировщика. Проверьте поддержку TLS 1.3, настройку групп, способ получить сведения о согласованной группе и наличие известных ограничений для конкретной сборки. Не переносите утверждение о поддержке из документации одной версии на другую и не делайте вывод о включённом режиме по одному названию параметра. Для OpenSSL, например, следует сверять доступные интерфейсы настройки групп и получения результата с документацией по группам и API согласования.

Этап организации стенда: перечислить участников

В таблице — минимальные варианты размещения проверок и то, какой вывод допустимо из них делать. Это не рейтинг производительности: применимость зависит от того, где завершается TLS и насколько стенд повторяет реальный маршрут соединения.

Вариант проверки	Что он позволяет подтвердить	Ограничение и подходящее применение
Локальные клиент и сервер	Поведение двух выбранных реализаций без внешнего сетевого пути	Не проверяет рабочий балансировщик, прокси или настройки конечных пользователей; годится для первоначальной диагностики
Изолированный стенд с посредниками	Согласование группы по маршруту, близкому к рабочему, и обработку сообщений сетевыми компонентами	Нужна конфигурация, представляющая фактические точки завершения TLS; использовать для проверки совместимости и отказов
Ограниченная рабочая выборка	Реакцию реальных клиентов и инфраструктуры при ограниченном охвате	Требует заранее заданных критериев остановки и процедуры возврата; переходить к ней следует только после стендовых испытаний

Для каждого участника составьте перечень сведений: программный компонент и его версия, роль в соединении, поддерживаемая версия TLS, источник сведений о поддержке группы и способ наблюдать фактический результат. Отдельно включите прокси и балансировщики: они могут завершать TLS, устанавливать новое соединение к следующему узлу либо пропускать шифрованный поток без завершения. В зависимости от схемы это разные точки наблюдения, поэтому одна проверка на входе не всегда описывает всю цепочку.

Зафиксируйте исходное состояние до изменения. Запишите действующую конфигурацию групп, известный результат базового рукопожатия, применяемые проверки сертификатов и место, где собираются диагностические данные. Такой снимок позволит отличить регрессию от уже существовавшей ошибки и восстановить предыдущую настройку, не полагаясь на память участников выпуска.

Этап первого рукопожатия: подтвердить фактическую группу

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

Используйте предусмотренный вашей реализацией источник результата: диагностический вывод поддерживаемого инструмента либо документированный интерфейс TLS-библиотеки. В документации применяемой версии OpenSSL проверьте, как задаются группы и как приложение получает согласованную группу; не подменяйте этот результат чтением входной конфигурации. Если инструмент показывает только предложенные клиентом группы, он ещё не доказывает, какую из них выбрал сервер.

В протокол испытания включите такие поля:

• проверяемое имя узла и точку завершения TLS;
• клиент, сервер, библиотека и их версии;
• согласованная версия TLS и группа, если диагностический интерфейс её показывает;
• результат проверки сертификата и завершения рукопожатия;
• время запуска, тестовый маршрут и связанные диагностические сообщения.

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

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

Этап совместимости: проверить смешанный парк

После подтверждения первого рукопожатия переходите к матрице совместимости. В ней должны быть новые и прежние клиенты, каждая фактически используемая точка TLS-терминации, а также посредники, которые могут менять параметры соединения. Не считайте две программы совместимыми только потому, что обе отдельно заявляют поддержку TLS 1.3: важно проверить их взаимодействие в нужной конфигурации и через реальный маршрут.

Для каждой комбинации проведите как минимум проверки успешного согласования, ожидаемого поведения при отсутствии общей группы и прохождения прикладного запроса после рукопожатия. Если в маршруте есть прокси или балансировщик, сравните прямое соединение со сценарием через этот компонент. Это помогает локализовать проблему: если прямой тест проходит, а соединение через посредника нет, область дальнейшего расследования сужается до его роли и настроек.

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

Для проверки отката заранее определите, что именно считается ожидаемым результатом при неподдерживаемом варианте: отказ соединения, выбор другой разрешённой группы или иной сценарий, предусмотренный конфигурацией и документацией реализации. Откат не следует считать исправным лишь потому, что клиент «в итоге подключился»: выясните, какая группа согласована и не отключили ли сопутствующие проверки безопасности. Убедитесь также, что процедура возврата конфигурации применима отдельно к каждой точке завершения TLS.

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

Этап решения о выпуске: определить охват и откат

Расширять охват можно, когда согласованная группа наблюдаема, проверены основные клиентские сочетания, посредники прошли испытания, а сценарий при неподдерживаемом варианте понятен и воспроизводим. Если хотя бы одна обязательная комбинация остаётся непроверенной, зафиксируйте её как блокирующий риск или явно ограничьте область выпуска. Не заменяйте это условие общей рекомендацией «включить всем»: парк клиентов, устройство сети и реализация TLS у каждой службы могут различаться.

Для выпуска назначьте владельца наблюдения и заранее определите условия остановки: рост ошибок установления соединения, повторяемые сбои на конкретном сегменте или невозможность отличить согласование новой группы от обычного TLS-соединения. Пороговые значения должны вытекать из рабочих показателей конкретной службы, а не заимствоваться как универсальные проценты. После ограниченного этапа сопоставьте результаты с исходным состоянием и только затем решайте, расширять ли выборку. Если метрики не позволяют локализовать ошибку или возврат конфигурации не проверен, расширение следует отложить.

В записи приёмки оставьте:

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

Такой журнал нужен не только для аудита. Он позволяет повторить тест после обновления библиотеки или балансировщика и выяснить, изменилось ли поведение конкретного компонента. При изменении статуса RFC, исправлении стандарта или появлении новой официальной информации о реализации процедуру следует пересмотреть; сам факт обновления стандарта не заменяет повторную проверку системы.

Частые вопросы

Как подтвердить, что в TLS 1.3 согласована именно X25519MLKEM768?
Нужно получить результат установленного соединения через диагностический интерфейс реализации или поддерживаемый инструмент, показывающий согласованную группу. Запись названия в конфигурации говорит только о настройке. Сверьте также версию TLS, точку завершения соединения и версии участников; тест с другим клиентом или на обходном сетевом маршруте не подтверждает поведение исходного пути.

Как разбирать ошибку рукопожатия или откат после включения ML-KEM?
Сначала фиксируют фазу отказа, доступные сведения о согласовании и сообщения обеих сторон. Затем воспроизводят случай без посредника и с одним известным совместимым участником, изменяя по одному условию. Откат считают проверенным после подтверждения ожидаемой группы и успешной прикладной проверки, а не просто после появления соединения.

Каково значение RFC 10024 для клиента и сервера?
RFC определяет механизм гибридного обмена ключами в TLS 1.3, но не включает его автоматически в конкретном продукте. Клиенту нужно поддерживать предложение группы, серверу — корректно обработать его, а совместимость зависит от обеих реализаций и сетевого пути. Проверяйте поддержку по официальным документам используемых версий и подтверждайте её результатом рукопожатия.

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

Выбор тестовой среды и следующий шаг

Если текущая проверка проводится на локальных машинах, её результат может не учитывать различия рабочих клиентских систем; общая тестовая среда может не повторять настройки точки TLS-терминации; универсальная виртуальная машина не заменит проверку клиента, работающего именно в macOS. Поэтому смена среды сама по себе не доказывает поддержку ML-KEM: важны проверяемая сборка TLS, наблюдаемость рукопожатия и соответствие сетевого маршрута целевому сценарию.

Для случая, когда требуется проверить именно клиент на macOS, можно рассмотреть аренду Mac mini в Zutcloud, предварительно уточнив, доступно ли нужное программное обеспечение и подходит ли способ доступа для этой задачи. Это может быть отдельным тестовым узлом, но не заменяет проверку серверной стороны, балансировщиков и производственного маршрута; никаких утверждений о поддержке конкретной TLS-сборки без её фактической проверки делать нельзя. Если требуется уточнить применимость среды к тестовому плану, условия можно обсудить через контактную страницу Zutcloud.

Если сервис уже тестируется на локальной машине или в общей среде, сначала сохраните описанный набор версий и критериев приёмки. Переход к арендованному Mac имеет смысл только при необходимости изолированно проверить совместимость клиентской части с macOS; для длительной стабильной нагрузки или требований к физическим интерфейсам следует отдельно оценить локальное оборудование и другие подходящие среды.

FAQ

Как убедиться, что соединение TLS 1.3 действительно согласовало X25519MLKEM768?

Проверяйте результат установленного соединения в диагностике TLS-библиотеки или поддерживаемом инструменте, который показывает согласованную группу. Наличие X25519MLKEM768 в конфигурации подтверждает только настройку предложения, но не выбор группы другой стороной. Сохраните вывод вместе с версиями клиента, сервера и библиотеки; отдельно убедитесь, что проверялось именно TLS 1.3-соединение, а не другой тестовый канал.

Что проверять, если после включения ML-KEM рукопожатие завершается ошибкой или соединение откатывается?

Зафиксируйте точный этап сбоя, согласованную версию протокола, предложенные группы и диагностические сообщения обеих сторон. Затем повторите проверку с известным совместимым клиентом и без промежуточного прокси, не меняя сразу несколько параметров. Откат считайте подтверждённым только тогда, когда установленный результат соответствует ожидаемому сценарию, а соединение проходит прикладные проверки.

Что RFC 10024 меняет для TLS-клиента и TLS-сервера?

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

Какие проверки совместимости нужны до выпуска постквантового TLS?

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