Во время Недели безопасности 2025 года мы представили первое в отрасли облачное постквантовое решение Secure Web Gateway (SWG) и Zero Trust, что стало важным шагом на пути к защите корпоративного сетевого трафика, передаваемого с пользовательских устройств в публичные и частные сети.
Но это лишь часть уравнения. Для полной защиты будущего корпоративных сетей необходимо комплексное решение Secure Access Service Edge (SASE).
Сегодня мы завершаем уравнение: Cloudflare One — это первая платформа SASE, поддерживающая современную постквантовую (PQ) криптографию, соответствующую стандартам, в нашем Secure Web Gateway, а также в сценариях использования Zero Trust и глобальной сети (WAN). Если точнее, Cloudflare One теперь предлагает гибридный постквантовый ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism) для всех основных точек входа и выхода.
Для завершения уравнения мы добавили поддержку постквантового шифрования в наш Cloudflare IPsec (наше облачное решение WAN-as-a-Service) и Cloudflare One Appliance (наше физическое или виртуальное устройство WAN, которое устанавливает соединения Cloudflare IPsec). Cloudflare IPsec использует протокол IPsec для установки зашифрованных туннелей из сети клиента в глобальную сеть Cloudflare, а технология IP Anycast используется для автоматической маршрутизации этого туннеля в ближайший дата-центр Cloudflare. Cloudflare IPsec упрощает конфигурацию и обеспечивает высокую доступность; если конкретный дата-центр становится недоступным, трафик автоматически перенаправляется к ближайшему работоспособному дата-центру. Cloudflare IPsec работает в масштабах нашей глобальной сети и поддерживает соединения типа "сайт-сайт" через WAN, а также исходящие подключения к Интернету.
Обновление Cloudflare One Appliance общедоступно, начиная с версии устройства 2026.2.0. Обновление Cloudflare IPsec находится в закрытой бета-версии, и вы можете попасть в список, обратившись к своей учетной команде по адресу pq-wan@cloudflare.com.
Постквантовая криптография важна уже сейчас
Квантовые угрозы — это не проблема "следующего десятилетия". Вот почему наши клиенты уже сегодня уделяют приоритетное внимание постквантовой криптографии (PQC):
Сроки приближаются. В конце 2024 года Национальный институт стандартов и технологий (NIST) послал четкий сигнал (который был поддержан другими агентствами): эра классической криптографии с открытым ключом подходит к концу. NIST установил срок до 2030 года для отказа от RSA и эллиптической криптографии (ECC) и перехода к PQC, которую не смогут взломать мощные квантовые компьютеры. Организации, которые не начали миграцию, рискуют оказаться несоответствующим требованиям и уязвимыми по мере приближения дедлайна.
Обновления исторически были сложными. Хотя 2030 год может казаться далеким, обновление криптографических алгоритмов печально известно своей сложностью. История показывает, что отказ от криптографии может занимать десятилетия: мы находили примеры, когда MD5 вызывал проблемы спустя 20 лет после его устаревания. Отсутствие криптографической гибкости — возможности легко заменять криптографические алгоритмы — является основным препятствием. Интегрируя PQ-шифрование напрямую в Cloudflare One, нашу платформу SASE, мы обеспечиваем встроенную криптографическую гибкость, упрощая для организаций предоставление удаленного доступа и соединений типа "сайт-сайт".
Данные уже могут быть под угрозой. Наконец, стратегия "Собрать сейчас, расшифровать позже" представляет собой текущую и постоянную угрозу, когда злоумышленники собирают конфиденциальный сетевой трафик сегодня и хранят его до тех пор, пока квантовые компьютеры не станут достаточно мощными для его расшифровки. Если срок хранения ваших данных составляет более нескольких лет (например, финансовая информация, медицинские данные, государственные секреты), они уже находятся под угрозой, если не защищены PQ-шифрованием.
Два этапа миграции на пути к квантовой безопасности: согласование ключей и цифровые подписи
Переход сетевого трафика на постквантовую криптографию (PQC) требует переработки двух криптографических примитивов: согласования ключей и цифровых подписей.
Миграция 1: Установление ключа. Согласование ключей позволяет двум сторонам установить общий секрет по незащищенному каналу; этот общий секрет затем используется для шифрования сетевого трафика, что приводит к постквантовому шифрованию. Отрасль в значительной степени сошлась на ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism) как стандартном протоколе PQ для согласования ключей.
ML-KEM широко adopted для использования в TLS, обычно развертываясь вместе с классическим алгоритмом Elliptic Curve Diffie Hellman (ECDHE), где ключ, используемый для шифрования сетевого трафика, получается путем смешивания выходных данных согласования ключей ML-KEM и ECDHE. (Это также известно как "гибридный ML-KEM"). Уже более 60% TLS-трафика, генерируемого людьми в сеть Cloudflare, в настоящее время защищено гибридным ML-KEM. Переход на гибридный ML-KEM был успешным, потому что он:
-
останавливает атаки "собрать-сейчас, расшифровать-позже"
-
не требует специализированного оборудования или специального физического соединения между клиентом и сервером, в отличие от подходов, таких как Квантовое распределение ключей (QKD)
-
практически не влияет на производительность, даже для кратковременных TLS-соединений
Поскольку ML-KEM работает параллельно с классическим ECDHE, по сравнению с классическим подходом ECDHE не происходит снижения уровня безопасности и соответствия требованиям.
Миграция 2: Цифровые подписи. Между тем, цифровые подписи и сертификаты защищают аутентичность, предотвращая попытки активных злоумышленников выдать себя за сервер перед клиентом. К сожалению, PQ-подписи в настоящее время имеют больший размер, чем классические алгоритмы ECC, что замедлило их внедрение. К счастью, миграция на PQ-подписи менее срочна, потому что они предназначены для остановки активных противников, вооруженных мощными квантовыми компьютерами, которые, как известно, еще не существуют. Таким образом, хотя Cloudflare активно участвует в стандартизации и внедрении PQ-цифровых подписей, текущее обновление Cloudflare IPsec фокусируется на обновлении установления ключа до гибридного ML-KEM.
Агентство по кибербезопасности и безопасности инфраструктуры США (CISA) признало характер этих двух миграций в своей публикации января 2026 года "Категории продуктов для технологий, использующих стандарты постквантовой криптографии".
Прокладывая новый путь с IPsec
Чтобы достичь SASE, полностью защищенного постквантовым шифрованием, мы обновили наши продукты Cloudflare IPsec для поддержки гибридного ML-KEM в протоколе IPsec.
Путь сообщества IPsec к постквантовой криптографии сильно отличался от пути TLS. TLS — де-факто стандарт для шифрования публичного интернет-трафика на 4-м уровне — например, от браузера к сети доставки контента (CDN) — поэтому безопасность и совместимость между вендорами находятся в авангарте его дизайна. В то же время IPsec — это протокол 3-го уровня, который обычно соединяет устройства, созданные одним и тем же вендором (например, два маршрутизатора), поэтому совместимость исторически вызывала меньше беспокойства. Имея это в виду, давайте взглянем на путь IPsec в квантовое будущее.
Предварительно общие ключи? Квантовое распределение ключей?
RFC 8784, опубликованный в мае 2020 года, должен был стать постквантовым обновлением для IPsec Internet Key Exchange v2 (IKEv2), который используется для установления симметричных ключей, применяемых для шифрования IPsec-трафика. RFC 8784 подразумевает использование либо долгоживущих предварительно общих ключей (PSK), либо квантового распределения ключей (QKD). Ни один из этих подходов не является очень привлекательным.
RFC 8784 предлагает смешивать PSK с ключом, полученным из обмена Диффи-Хеллмана (DHE), по сути, используя PSK в гибридном режиме с DHE. Этот подход защищает от атакующих по схеме "собрать-сейчас-расшифровать-позже", но не обеспечивает совершенную прямую секретность против квантовых противников.
Прямая секретность (Forward secrecy) — стандартное желательное свойство протоколов согласования ключей. Она гарантирует, что система останется защищенной, даже если долгоживущий ключ будет скомпрометирован. Подход с PSK в RFC 8784 уязвим для противника, применяющего тактику "собрать сейчас — расшифровать позже", который также получит копию долгоживущего PSK и сможет в будущем (взломав согласование ключей DHE) расшифровать трафик, когда появятся мощные квантовые компьютеры.
Для решения этой проблемы прямой секретности RFC 8784 можно использовать иначе — смешивая ключ от классического DHE со свежесгенерированным ключом, полученным по протоколу QKD.
QKD использует законы квантовой механики для установки общего секретного криптографического ключа между двумя сторонами. Важно, что для работы QKD сторонам необходимо специализированное оборудование или выделенное физическое соединение. Это существенное ограничение, делающее QKD бесполезным для типичных сценариев использования в интернете, таких как подключение ноутбука к удалённому серверу по Wi-Fi. Эти ограничения — также причина, по которой мы никогда не инвестировали в развёртывание QKD для Cloudflare IPsec. Агентство национальной безопасности США (NSA), Федеральное ведомство Германии по информационной безопасности (BSI) и Национальный центр кибербезопасности Великобритании также предупреждали о рисках полагаться исключительно на QKD.
Но как насчёт совместимости?
RFC 9370 был опубликован в мае 2023 года, предписывая использование гибридного согласования ключей вместо PSK или QKD. Но в отличие от TLS, который поддерживает использование постквантового ML-KEM только параллельно с классическим DHE, этот стандарт IPsec допускает одновременное параллельное использование до семи различных методов согласования ключей вместе с классическим Диффи-Хеллманом. Более того, он не детализирует, какими именно должны быть эти методы, оставляя выбор алгоритмов и реализаций на усмотрение вендоров. Например, Palo Alto Networks серьёзно подошли к этому и внедрили поддержку более семи различных постквантовых наборов шифров (PQC ciphersuites) в свой межсетевой экран следующего поколения (NGFW), большинство из которых несовместимы с продуктами других вендоров, а некоторые ещё не стандартизированы NIST.
На протяжении лет TLS двигался в противоположном направлении, сокращая количество зарегистрированных наборов шифров с сотен в TLS 1.2 до примерно пяти в TLS 1.3. Эта философия сокращения «раздувания наборов шифров» также соответствует документу NIST SP 800-52 от 2019 года. Обоснование для сокращения «раздувания наборов шифров» включает:
-
Улучшенную совместимость между вендорами и регионами
-
Снижение риска атак, использующих понижение до слабых наборов шифров
-
Снижение риска проблем с безопасностью из-за ошибочной конфигурации
-
Снижение риска ошибок реализации за счёт уменьшения размера кодовой базы
Вот почему изначально мы не стали внедрять поддержку RFC 9370.
Стандарты, наконец, на верном пути
Именно поэтому мы были рады, когда сообщество IPsec выдвинуло draft-ietf-ipsecme-ikev2-mlkem. Этот черновик стандарта стандартизирует постквантовый обмен для IPsec тем же способом, которым постквантовый обмен ключами был широко внедрён для TLS: гибридный ML-KEM. Новый черновик заполняет пробелы в RFC 9370, указывая, как запускать ML-KEM в качестве дополнительного обмена ключами параллельно с классическим Диффи-Хеллманом в IKEv2.
Теперь, когда эта спецификация доступна, мы продолжили работу по поддержке постквантового IPsec в наших продуктах Cloudflare IPsec.
Cloudflare IPsec становится постквантовым
Cloudflare IPsec — это решение для глобальной сети (WAN) в формате «Сеть как услуга», которое заменяет устаревшие архитектуры частных сетей, подключая центры обработки данных, филиалы и облачные VPC к глобальной IP-сети Cloudflare Anycast.
В Cloudflare IPsec сеть Cloudflare выступает в роли IKEv2 Responder, ожидая запросы на подключение от инициатора IPsec, которым является устройство-коннектор филиала в сети клиента. Cloudflare IPsec поддерживает IPsec-сессии, инициированные коннекторами филиалов, включая наш собственный Cloudflare One Appliance, а также коннекторы от разнообразного набора вендоров, включая Cisco, Juniper, Palo Alto Networks, Fortinet, Aruba и других.
Мы внедрили промышленную поддержку гибридного ML-KEM в Cloudflare IPsec IKEv2 Responder, как указано в draft-ietf-ipsecme-ikev2-mlkem. Черновик требует, чтобы первый обмен ключами выполнялся с использованием классического Диффи-Хеллмана. Полученный ключ используется для шифрования второго обмена ключами, выполняемого с помощью ML-KEM. Наконец, ключи, полученные в результате двух обменов, смешиваются, и результат используется для защиты трафика плоскости данных в режиме ESP (Encapsulating Security Payload) IPsec. Режим ESP использует симметричную криптографию и, следовательно, уже защищён от квантовых атак без каких-либо дополнительных обновлений. Мы протестировали нашу реализацию на соответствие с инициатором IPsec в референс-реализации strongswan.
Используемый в переговорах IKEv2 набор шифров можно увидеть в журналах Cloudflare IPsec.
Мы решили реализовать гибридный ML-KEM, а не «чистый» ML-KEM (только ML-KEM без параллельного DHE), по двум причинам. Во-первых, мы использовали гибридный ML-KEM во всех других продуктах Cloudflare, поскольку этот подход принят в сообществе TLS. Во-вторых, это обеспечивает двойную защиту: ML-KEM защищает от квантовых атак «собрать сейчас — расшифровать позже», а DHE предоставляет проверенный алгоритм защиты от неквантовых противников.
Приглашение к совместимости
Полная ценность этой реализации может быть реализована только через совместимость. По этой причине мы приглашаем других вендоров, которые внедряют поддержку инициаторов IPsec в своих коннекторах филиалов согласно draft-ietf-ipsecme-ikev2-mlkem, протестировать взаимодействие с нашей реализацией Cloudflare IPsec. Клиенты Cloudflare, желающие протестировать совместимость со сторонними коннекторами филиалов, пока мы находимся в закрытой бета-версии, могут связаться с нами через свою команду по работе с клиентами или написав на pq-wan@cloudflare.com. Мы планируем выпустить продукт в общий доступ и наладить совместимость с другими вендорами по мере того, как всё больше из них начнут поддерживать draft-ietf-ipsecme-ikev2-mlkem.
Квантово-безопасное оборудование: Cloudflare One Appliance
Многие наши клиенты приобретают свои коннекторы филиалов (аппаратные или виртуальные) у Cloudflare, а не у сторонних вендоров. Вот почему Cloudflare One Appliance — наше устройство plug-and-play, подключающее вашу локальную сеть к Cloudflare One — также было обновлено с поддержкой постквантового шифрования.
Cloudflare One Appliance не использует IKEv2 для согласования ключей или установления сессии, предпочитая полагаться на TLS. Устройство периодически инициирует TLS-рукопожатие с периферийной сетью Cloudflare, передаёт симметричный секрет через установленное TLS-соединение, а затем внедряет этот симметричный секрет в ESP-слой IPsec, который затем шифрует и аутентифицирует трафик плоскости данных IPsec. Эта конструкция позволила нам избежать создания логики инициатора IKEv2 и делает коннектор проще в поддержке с использованием наших существующих TLS-библиотек.
Таким образом, обновление Cloudflare One Appliance до постквантового шифрования было всего лишь вопросом обновления TLS 1.2 до TLS 1.3 с гибридным ML-KEM — то, что мы уже много раз делали в различных продуктах Cloudflare.
Как это включить? И сколько это стоит?
Как всегда, это обновление Cloudflare IPsec не требует от наших клиентов дополнительных затрат. Поскольку мы верим, что безопасный и приватный интернет должен быть доступен каждому, наша миссия — включить PQC во все наши продукты, без необходимости в специализированном оборудовании, и без дополнительной платы для наших клиентов и конечных пользователей.
Клиенты, использующие устройство Cloudflare One Appliance, получили это обновление до PQC в версии 2026.2.0 (выпущена 2026-02-11). Обновление автоматически применяется (не требуя действий от клиента) в соответствии с настроенным для каждого устройства окном обслуживания.
Для клиентов, использующих Cloudflare IPsec с устройством-коннектором ветки другого вендора, мы обеспечим взаимодействие с ними, как только появится более широкая поддержка draft-ietf-ipsecme-ikev2-mlkem. Вы также можете связаться с нами напрямую, чтобы получить доступ к закрытой бета-версии и запросить обеспечение взаимодействия с конкретным вендорским коннектором ветки, обратившись к вашей аккаунт-команде по адресу pq-wan@cloudflare.com.
Полная картина: пост-квантовый SASE
Ценностное предложение пост-квантового SASE очевидно: организации могут получить немедленную сквозную защиту для своего приватного сетевого трафика, пропуская его через туннели, защищенные гибридным ML-KEM. Это защищает трафик от атак типа "собрать сейчас — расшифровать позже", даже если отдельные приложения в корпоративной сети еще не обновлены до PQC.
На приведенной выше схеме показано, как гибридный пост-квантовый ML-KEM предлагается в различных конфигурациях сети Cloudflare One. Она включает следующие точки входа (on-ramps):
-
Бесклиентовый доступ (TLS 1.3 с гибридным ML-KEM (при условии поддержки браузером гибридного ML-KEM))
-
Cloudflare One Client (MASQUE поверх TLS 1.3 с гибридным ML-KEM, инициируемый клиентом на устройстве)
-
Точка входа Cloudflare IPsec (как описано в этом блоге)
и следующие точки выхода (off-ramps):
-
Точка выхода Cloudflare Tunnel (TLS 1.3 с гибридным ML-KEM туннелем, инициируемая клиентом cloudflared на устройстве)
-
Точка входа Cloudflare IPsec (как описано в этом блоге)
На схеме ниже выделен пример сетевой конфигурации, которая использует точку входа Cloudflare One Client для подключения устройства к серверу за точкой выхода Cloudflare One Appliance. Устройство конечного пользователя подключается к сети Cloudflare (соединение 1), используя MASQUE с гибридным ML-KEM. Затем трафик проходит через глобальную сеть Cloudflare по TLS 1.3 с гибридным ML-KEM (соединение 2). После этого трафик покидает сеть Cloudflare через пост-квантовое соединение Cloudflare IPsec (соединение 3), которое завершается на устройстве Cloudflare One Appliance. Наконец, он подключается к серверу внутри среды заказчика. Трафик защищен пост-квантовой криптографией при передаче через публичный Интернет, даже если сам сервер не поддерживает пост-квантовую криптографию.
Наконец, отметим, что трафик, который поступает в Cloudflare One и затем направляется в публичный Интернет, также может быть защищен нашим пост-квантовым Cloudflare Gateway, нашим Secure Web Gateway (SWG). Вот диаграмма, показывающая, как работает SWG:
Как обсуждалось в предыдущем посте блога, наш SWG уже может поддерживать гибридный ML-KEM на трафике от SWG до сервера-источника (при условии, что источник поддерживает гибридный ML-KEM), и на трафике от клиента до SWG (если клиент поддерживает гибридный ML-KEM, что справедливо для большинства современных браузеров). Важно, что любой трафик, который поступает в SWG через устройство с установленным Cloudflare One Client, по-прежнему защищен гибридным ML-KEM — даже если сам веб-браузер еще не поддерживает пост-квантовую криптографию. Это обеспечивается пост-квантовым туннелем MASQUE, который Cloudflare One Client устанавливает с глобальной сетью Cloudflare. То же самое справедливо для трафика, который поступает в SWG через пост-квантовый туннель Cloudflare IPsec.
Обобщая, Cloudflare One теперь предлагает пост-квантовое шифрование на наших точках входа и выхода для TLS, MASQUE и IPsec, для трафика частной сети и для трафика, который направляется в публичный Интернет через наш SWG.
Будущее защищено от квантовых угроз
Завершив создание пост-квантового SASE с помощью Cloudflare IPsec и Cloudflare One Appliance, мы расширили пост-квантовое шифрование на все наши основные точки входа и выхода. Мы сознательно выбрали путь совместимости и простоты — подход гибридного ML-KEM, который продвигают IETF и NIST, вместо того чтобы ограничивать наших клиентов проприетарными реализациями, "раздуванием набора шифров" или ненужными обновлениями оборудования.
В этом заключается обещание Cloudflare One: платформа SASE, которая не только быстрее и надежнее устаревших архитектур, которые она заменяет, но и обеспечивает пост-квантовое шифрование. Независимо от того, защищаете ли вы браузер удаленного сотрудника или многогигабитное соединение центра обработки данных, теперь вы можете делать это с уверенностью, что ваши данные защищены от атак "собрать сейчас — расшифровать позже" и других угроз, ориентированных на будущее.