INTEGRITY Документация

← Cloudflare SSL/TLS / ssl / post-quantum-cryptography

Постквантовое шифрование между Cloudflare и исходными серверами

На этой странице рассматривается постквантовая криптография для TLS-соединения между периферийной сетью Cloudflare и вашим исходным сервером. Cloudflare поддерживает как постквантовое согласование ключей (X25519MLKEM768) и постквантовые подписи (ML-DSA через Authenticated Origin Pulls и Custom Origin Trust Store) для этого соединения.

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

Постквантовое согласование ключей

Как описано в О PQC, Cloudflare внедрила поддержку гибридного согласования ключей, включающего как наиболее распространённый для TLS 1.3 алгоритм X25519, так и постквантовый защищённый ML-KEM.

При использовании X25519 ClientHello ↗ почти всегда помещается в один сетевой пакет. Однако с добавлением ML-KEM сообщение ClientHello обычно делится на два пакета.

Возникает вопрос, как исходные серверы, а также другие промежуточные устройства (маршрутизаторы, балансировщики нагрузки и так далее), отреагируют на это изменение поведения. Хотя это допускается стандартом TLS 1.3 (RFC 8446 ↗), разделённый ClientHello может обрабатываться некорректно из-за окостенение протокола ↗ и ошибок реализации. См. нашу запись в блоге ↗ для получения подробностей.

ClientHello от Cloudflare

Cloudflare использует автоматический обмен ключами чтобы узнать, какие варианты согласования ключей предпочитают исходные серверы вашей зоны. Cloudflare применяет единое предпочтение на уровне зоны. Когда выбранным предпочтением является X25519MLKEM768, Cloudflare отправляет этот key share в первоначальном ClientHello для более быстрого установления соединения.

Cloudflare продолжает анонсировать остальные разрешённые механизмы согласования ключей. Если источнику нужен другой key share, он может использовать HelloRetryRequest ↗ чтобы запросить его. Повторная попытка добавляет одно дополнительное обращение по сети, но не разрывает соединение.

Настройка

Настройки зоны Cloudflare

Automatic key exchange включён для всех существующих зон и включён по умолчанию для новых зон. Если источник поддерживает и классические, и постквантовые варианты, Cloudflare отдаёт предпочтение постквантовому согласованию ключей.

Используйте Automatic key exchange для управления сканированием и выбором предпочтительного key share. Требования соответствия применяются только к соединениям TLS 1.3.

Origin Post-Quantum Encryption API остается доступным. Запросы к этому API не выполняют никаких действий и не изменяют поведение согласования постквантовых ключей зоны. Cloudflare планирует прекратить поддержку этого API, но дата прекращения поддержки пока не установлена.

Origin server

Чтобы исходный сервер отдавал предпочтение постквантовому согласованию ключей, используйте bssl инструмент из BoringSSL ↗:

bssl client -connect <YOUR_ORIGIN>:443 -curves X25519MLKEM768

Убедитесь, что ECDHE curve в выводе рукопожатия означает X25519MLKEM768.

Постквантовые подписи

С середины 2026 года Cloudflare поддерживает ML-DSA ↗ постквантовые подписи в двух функциях, обращенных к источнику:

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

Требования

Создание удостоверяющего центра ML-DSA и конечного сертификата

Приведённые ниже команды создают приватный удостоверяющий центр (CA) и конечный сертификат, связанный с ним цепочкой, с использованием ML-DSA-44. Повторите эти действия один раз для клиентского сертификата AOP и один раз для серверного сертификата COTS, если вы также управляете этой стороной.

# Private ML-DSA-44 CA (30-year validity)
openssl genpkey \
  -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out ca.key
openssl req -new -x509 \
  -key ca.key \
  -out ca.crt \
  -days 10950 \
  -subj "/CN=ML-DSA Origin CA"

# Leaf certificate signed by the CA (15-year validity)
openssl genpkey \
  -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out leaf.key
openssl req -new \
  -key leaf.key \
  -out leaf.csr \
  -subj "/CN=origin.example.com" \
  -addext basicConstraints=CA:FALSE \
  -addext keyUsage=digitalSignature \
  -addext subjectAltName=DNS:origin.example.com
openssl x509 -req \
  -in leaf.csr \
  -CA ca.crt -CAkey ca.key \
  -CAcreateserial \
  -out leaf.crt \
  -days 5475 \
  -copy_extensions copy

-provparam ml-dsa.output_formats=seed-only флаг необходим, чтобы закрытый ключ записывался в виде seed по стандарту FIPS 204, а не в виде развёрнутого закрытого ключа. На данный момент Cloudflare принимает при загрузке только этот формат.

Проверьте созданный сертификат:

openssl x509 -in leaf.crt -noout -subject -issuer -dates -ext subjectAltName

Настройка Authenticated Origin Pulls с клиентским сертификатом ML-DSA

Клиентские сертификаты ML-DSA поддерживаются как с на уровне зоны и для каждого имени хоста AOP. Создайте CA и leaf-сертификат ML-DSA, как описано в Создание удостоверяющего центра ML-DSA и конечного сертификата, затем следуйте руководству по настройке для нужной области применения. глобальный AOP область использует сертификат, предоставленный Cloudflare, и не настраивается.

На сервере источника установите корневой сертификат CA для ML-DSA (файл ca.crt файл, созданный ранее), чтобы ваш TLS-сервер мог проверять клиентский сертификат, который предъявляет Cloudflare. Для nginx это выглядит так:

ssl_client_certificate /etc/ssl/cloudflare-aop-ca.crt;
ssl_verify_client      on;

См. Руководство по настройке AOP для origin-серверов для полной настройки на стороне источника.

Настройка Custom Origin Trust Store с CA на основе ML-DSA

Загрузите сертификат CA ML-DSA (тот же ca.crt файл, созданный ранее) в качестве Custom Origin Trust Store запись. После этого Cloudflare будет доверять любому сертификату исходного сервера, который образует цепочку до этого ЦС в режим шифрования Full (strict).

На стороне сервера-источника используйте конечный сертификат ML-DSA и соответствующий закрытый ключ в качестве серверного TLS-сертификата:

ssl_certificate     /etc/ssl/origin-mldsa.pem;
ssl_certificate_key /etc/ssl/origin-mldsa.key;
ssl_protocols       TLSv1.3;

Сквозная проверка

После настройки AOP и COTS вы можете проверить постквантовое рукопожатие с источником с хоста, поддерживающего ML-DSA. Например, с машины с OpenSSL версии 3.5.0 или новее подключитесь напрямую к вашему источнику и убедитесь, что рукопожатие использует ML-DSA:

openssl s_client \
  -connect origin.example.com:443 \
  -servername origin.example.com \
  -CAfile ca.crt \
  -cert leaf.crt \
  -key leaf.key \
  -brief

В выводе должно отображаться Signature type: mldsa44 и Negotiated TLS1.3 group: X25519MLKEM768.

Не допускайте понижения уровня безопасности

Одного лишь предъявления сертификата ML-DSA на аутентифицирующей стороне недостаточно. Чтобы действительно получить постквантовую аутентификацию, необходимо, чтобы проверка сторона должна отклонять классические (непостквантовые) сертификаты. Если проверяющая сторона всё ещё принимает классический сертификат, злоумышленник, скомпрометировавший этот классический ключ, может выдать себя за узел с помощью атака на пути ↗ : понижение, которое сводит на нет постквантовую защиту.