Cloudflare объявила о планах выпускать TLS-сертификаты, устойчивые к атакам с использованием квантовых компьютеров. Сертификаты будут построены на деревьях Меркла (Merkle Tree Certificates) и выдаваться бесплатно всем пользователям. На момент публикации сертификаты ещё не выпускаются: компания планирует начать выдачу в первом квартале 2027 года.
Отдельно Cloudflare описывает механику постквантового согласования ключей между своим периметром и origin-серверами — эту часть можно включить уже сейчас через API.
Что именно изменилось
План Cloudflare опирается на платформу с открытым исходным кодом, которая умеет выпускать как традиционные TLS-сертификаты, так и их постквантовые аналоги — сертификаты на основе деревьев Меркласертификаты, подлинность которых подтверждается компактными доказательствами на основе деревьев Меркла вместо многозвенной цепочки подписей. Дерево Меркла — это структура, в которой множество подписей сводится к одному компактному доказательству, поэтому такая замена позволяет резко сократить объём данных при установлении соединения по сравнению с цепочкой подписей. Для доверия к новым сертификатам компания будет использовать уже пользующийся доверием корневой сертификат удостоверяющего центра GlobalSign. По заявлению Cloudflare, это позволит миллионам сайтов начать использовать постквантовые сертификаты практически мгновенно, без снижения производительности.
Сертификаты выдаются автоматически через Universal SSLмеханизм Cloudflare, который автоматически выпускает бесплатные сертификаты для корневого домена и поддоменов первого уровня. Total TLSмеханизм Cloudflare, который расширяет покрытие Universal SSL, автоматически выпуская сертификаты для проксируемых хостов на любом уровне поддоменов.
В план также входит ACME (Automated Certificate Management Environment) — механизм с открытым исходным кодом для выпуска сертификатов и их автоматического продления незадолго до истечения срока действия. Сертификаты, устойчивые к квантовым вычислениям, обеспечат возможность передачи цифровых подписей по альтернативным каналам, например посредством обновления браузера.
Как устроена постквантовая защита соединений
Для защиты от сценария «сохранить сейчас, расшифровать потом» применяется гибридная схема X25519Kyber768Draft00 — комбинация двух согласований ключапроцедур, в ходе которых две стороны по открытому каналу вырабатывают общий секретный ключ для шифрования сессии: X25519 и предварительной версии Kyberпостквантового алгоритма согласования ключей, выбранного NIST. Гибридность нужна на случай, если Kyber окажется сломан: тогда сохраняется неквантовая стойкость X25519.
Kyber768 выбран вместо Kyber512, хотя Kyber512 не показывает признаков несоответствия целевому уровню безопасности: дизайнеры Kyber предпочитают более широкий запас прочности Kyber768, и Cloudflare следует их совету. Производительность Kyber768 высокая — 31 000 операций/с у клиента и 70 000 у сервера, — но гибрид X25519Kyber768Draft00 медленнее X25519: 11 000 и 14 000 операций/с соответственно. Клиент при подключении отправляет 1 184 дополнительных байт для Kyber в первом сообщении.
Со стороны стандартов постквантовые подписи опираются на FIPS 204федеральный стандарт обработки информации США, определяющий набор алгоритмов постквантовых цифровых подписей, который определяет ML-DSAнабор алгоритмов для генерации и проверки цифровых подписей, стойких к атакам с использованием крупномасштабного квантового компьютера. Цифровые подписи служат для обнаружения несанкционированных изменений данных и подтверждения личности подписанта, а также как доказательство третьей стороне (неотрицаемость).
Почему это сделали
Нынешняя система WebPKIинфраструктура открытых ключей для проверки подлинности сертификатов в интернете для подтверждения подлинности сертификата опирается на многозвенную цепочку подписей, уязвимых к атакам с использованием квантовых компьютеров. Замена этих подписей на устойчивые к квантовым вычислениям аналоги потребовала бы чрезмерных ресурсов: использование постквантовых версий современных классических сертификатов X.509 увеличило бы примерно в 40 раз объём данных, передаваемых при TLS-рукопожатии в начале нового сеанса связи с сервером. Дополнительные вычислительные затраты и нагрузка на пропускную способность сети, необходимые для такой системы, привели бы к краху привычного интернета.
Вместо этого цепочки подписей заменяют компактными доказательствами на основе деревьев Меркла. Эта технология, которую Google и Cloudflare уже тестируют в рамках ограниченных пилотных проектов, позволяет сократить объём данных при установлении соединения примерно до 40 килобайт — это сопоставимо с текущими размерами обрабатываемых данных.
Из конкретных инцидентов авторы ссылаются на взлом нидерландской компании DigiNotar в 2011 году, в результате которого злоумышленники смогли выпустить 500 поддельных сертификатов для Google и других известных сайтов. Именно в ответ на этот инцидент были внедрены программы обеспечения прозрачности.
Что это меняет на практике
Управлять постквантовым шифрованием между Cloudflare и origin-сервером можно через API: включить досрочно (opt-in) или заранее отказаться (opt-out). Запрос выполняется методом PUT на адрес https://api.cloudflare.com/client/v4/zones/(zone_id)/cache/origin_post_quantum_encryption с телом {"value": "(setting)"}.
Параметр setting принимает одно из трёх значений:
- supportedрежим, в котором Cloudflare объявляет поддержку постквантового согласования ключей, но в первом ClientHello отправляет классический keyshare; постквантовое соединение устанавливается, только если origin сам предпочитает постквантовое согласование, и тогда добавляется лишний roundtrip;
- preferredрежим, в котором Cloudflare сразу отправляет постквантовый keyshare; достаточно, чтобы origin поддерживал постквантовое согласование ключей, и соединение устанавливается без лишнего roundtrip;
- offрежим, в котором постквантовое шифрование между Cloudflare и origin-сервером отключено.
Аутентификация — через API token, который создаётся в дашборде с правами zone → zone settings → edit; zone_id — идентификатор зоны, который можно посмотреть в дашборде.
Чтобы включить постквантовое соединение сегодня и пропустить постепенное развёртывание, нужно выполнить opt-in зоны, установив значение preferred. Перед развёртыванием поддержки для enterprise-клиентов в феврале 2024 года в дашборде появится переключатель для opt-out.
Требования к origin-серверу: поддержка TLS 1.3, включение и предпочтение соглашения о ключе X25519Kyber768Draft00, а также настроенное серверное предпочтение шифров. В примере конфигурации nginx это выражается директивами ssl_ecdh_curve X25519Kyber768Draft00:X25519, ssl_prefer_server_ciphers on и ssl_protocols TLSv1.3.
Проверить настройку можно утилитой bssl из BoringSSL командой вида bssl client -connect (your server):443 -curves X25519:X25519Kyber768Draft00. В выводе нужно искать строку ECDHE curve: X25519Kyber768Draft00 — это признак постквантового соединения; если стоит просто X25519, постквантовое согласование не задействовано. Такая проверка достаточна, когда зона настроена в режиме preferred.
Проблемы совместимости
Основная сложность развёртывания — protocol ossificationситуация, когда промежуточные устройства жёстко зашиты под текущий формат протокола и ломаются при его изменении. В 2019 году, в ходе более ранних постквантовых экспериментов, промежуточные устройства одного из производителей отбрасывали соединения с разделённым ClientHelloпервое сообщение TLS-рукопожатия, в котором клиент перечисляет поддерживаемые параметры и отправляет свои доли ключей.
Для обхода используется HelloRetryRequest: в первом ClientHello отправляется только X25519 keyshare, а поддержка X25519+Kyber лишь объявляется. Если origin поддерживает постквантовое согласование, он может через HelloRetryRequest запросить его. Если не поддерживает — ничего не меняется, а объявление поддержки не ломает origin благодаря GREASE: браузеры отправляют кодовые точки из непредсказуемых диапазонов, чтобы усложнить реализацию ПО, спотыкающегося на неизвестных значениях.
Поломки возможны и при использовании HelloRetryRequest: неисправное промежуточное устройство, балансировщик или само серверное ПО могут не справиться с большим ClientHello с X25519+Kyber. Среди конкретных ошибок — выделение буфера всего 1000 байт в предположении, что ClientHello мал, и чтение ClientHello одним вызовом recv(), которому может потребоваться больше вызовов при разделении на несколько пакетов. Серверы на Rust TLS-библиотеке rustls некорректно реализовывали HelloRetryRequest до версии 0.21.7.
В режиме supported постквантовое соединение устанавливается, но с дополнительным roundtrip — это наиболее совместимый, но менее производительный способ включения.
Цифры и сроки
Сканирование активных origin-серверов выполняется примерно раз в 24 часа серией около десяти TLS-соединений — для проверки поддержки и предпочтений различных схем согласования ключей. Предварительные результаты: 0.5% origin поддерживают постквантовое соединение, а небольшая доля (<0.34%) origin не устанавливает соединение при отправке постквантового keyshare в первом ClientHello.
Доли поддержки и предпочтения по key agreement:
| Key agreement | supported | preferred |
|---|---|---|
| X25519 | 96% | 96% |
| P-256 | 97% | 0.6% |
| P-384 | 89% | 2.3% |
| P-521 | 82% | 0.1% |
| X25519Kyber768Draft00 | 0.5% | 0.5% |
Отдельно указано, что 4% origin-серверов отправляют HelloRetryRequest для других key agreements, таких как P-384.
Ограничения и открытые вопросы
Авторы признают, что приём с HelloRetryRequest даёт лишний roundtrip для origin, которые поддерживают постквантовое согласование, и это hurts performance. Убрать roundtrip можно настройкой зоны как preferred, но авторы считают, что лучшая настройка — та, которую не нужно трогать.
План — использовать результаты сканирования: позже в этом году они начнут определять лучшую настройку для зон, которые ещё не настроены, чтобы отправлять постквантовый keyshare сразу, без лишнего roundtrip.
Авторы прямо говорят, что приём с HelloRetryRequest лишь откладывает проблему: индустрии придётся починить сломанное оборудование и ПО, прежде чем включать постквантовое шифрование на каждом соединении. Открытый вопрос — точные причины сбоев у части origin: их исследуют и будут обращаться к вендорам.
