Cloudflare включила постквантовое шифрование в IPsec на гибридном ML-KEM
Hybrid ML-KEM в Cloudflare IPsec прошёл general availability 30 апреля 2026: классический Diffie-Hellman и ML-KEM в одном handshake защищают site-to-site WAN от harvest-now-decrypt-later атак. Цель полной post-quantum миграции — 2029.
Если у вас site-to-site VPN на железе Cisco 8000 или Fortinet FortiGate, и оно ходит в Cloudflare через IPsec — вы уже можете перевести туннели в post-quantum режим. 30 апреля 2026 Cloudflare объявила general availability hybrid ML-KEM в своём IPsec-сервисе: новый стандарт IETF (Internet Engineering Task Force, комитет по интернет-стандартам) — draft-ietf-ipsecme-ikev2-mlkem — совместимо тестируется с прошивками Cisco 8000 после 26.1.1 и FortiOS 7.6.6+. Защититься это помогает от атак harvest-now, decrypt-later: трафик собирают сегодня, чтобы расшифровать позже на квантовом компьютере. Это перевод поста Sharon Goldberg и Amos Paul из Cloudflare о том, почему IPsec догнал TLS в post-quantum только сейчас, через 4 года после TLS, — и при чём тут QKD, RFC 9370 и проблема ciphersuite bloat.
Ключевые выводы
- Что в GA: hybrid ML-KEM (Module-Lattice-based Key Encapsulation Mechanism — постквантовый алгоритм согласования ключей, стандартизирован NIST как FIPS 203 — федеральный стандарт США по постквантовой криптографии, утверждён в 2024) в Cloudflare IPsec через
draft-ietf-ipsecme-ikev2-mlkem. Hybrid — значит, что в одной handshake параллельно идут классический Diffie-Hellman и ML-KEM, а итоговый ключ собирается из обоих. - С каким железом совместимо: Cisco 8000 Series Secure Routers начиная с прошивки 26.1.1; Fortinet FortiOS 7.6.6 и выше. Это branch-коннекторы — устройства в филиалах, которые держат туннель к глобальной сети Cloudflare. Совместимость подтверждена тестированием с production-Cloudflare. Реализация Palo Alto Networks (на базе RFC 9370) пока не работает с Cloudflare — у них своя ciphersuite, выпущенная до появления draft.
- Зачем это нужно сейчас: Cloudflare сдвинула цель полного перехода на post-quantum cryptography на 2029 — после ускорений в квантовом железе. Защищаются прежде всего от атак harvest-now-decrypt-later: злоумышленник копит зашифрованный трафик сейчас, чтобы расшифровать позже, после Q-Day — момента, когда квантовые компьютеры станут достаточно мощными, чтобы сломать классические алгоритмы (RSA, ECDH, ECDSA).
- Почему IPsec догнал TLS только сейчас: четыре года разрыва. В TLS hybrid-ключи пошли в production в 2022 (на Cloudflare уже больше двух третей TLS-трафика идут через post-quantum). В IPsec спецификация hybrid ML-KEM появилась только в конце 2025. Часть задержки — споры вокруг QKD (Quantum Key Distribution).
- QKD не вариант: национальные службы информбезопасности США (NSA), Германии (BSI) и Великобритании (NCSC) предупреждают: полагаться только на QKD нельзя. Нужно специальное железо и выделенный физический канал, она не работает в масштабах интернета и не закрывает аутентификацию — подробнее — в FAQ.
Cloudflare IPsec в одном абзаце
Cloudflare IPsec — это WAN-as-a-service (Network-as-a-Service): он заменяет легаси-сетевые архитектуры тем, что подключает дата-центры, филиалы и облачные VPC к глобальной IP Anycast-сети Cloudflare. Клиенты получают упрощённую конфигурацию, high availability (если дата-центр падает, трафик уходит на ближайший живой) и масштаб глобальной сети Cloudflare. Туннели — IPsec, поддерживают site-to-site WAN, исходящие интернет-соединения и подключение к платформе Cloudflare One SASE.
Post-quantum в IPsec: hybrid ML-KEM
Cloudflare IPsec теперь использует post-quantum encryption через hybrid ML-KEM (FIPS 203), чтобы остановить harvest-now-decrypt-later атаки. Так называют сценарий, когда злоумышленник собирает зашифрованные данные сегодня — а расшифровывает их позже, после Q-Day, когда появятся достаточно мощные квантовые компьютеры, способные сломать классическую public-key криптографию, на которой построена безопасность интернета. Cloudflare пишет, что про эти атаки задумывается всё больше организаций, потому что Q-Day приближается быстрее, чем ожидалось.
ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) — это алгоритм post-quantum криптографии, основанный на математических задачах решёточной криптографии, для которых пока не известно эффективных квантовых атак. Он не требует специального железа или выделенного физического канала: ML-KEM спроектирован так, чтобы его можно было реализовать программно на обычных процессорах и шифровать им сетевой трафик.
Сам draft-ietf-ipsecme-ikev2-mlkem описывает post-quantum шифрование для IPsec через hybrid ML-KEM: классическая безопасность Diffie-Hellman (хорошо изученная и выдержавшая годы реальных атак) совмещается с post-quantum безопасностью ML-KEM в одном стандартизированном handshake. Конкретно: сначала отрабатывает классический Diffie-Hellman, его выходной ключ шифрует второй обмен с ML-KEM, и выходы обоих обменов подмешиваются в session keys, которые шифруют трафик IPsec data plane через ESP (Encapsulating Security Payload — основной протокол передачи зашифрованных пакетов в IPsec).
Совместимость, проверенная на железе
Раньше Cloudflare объявляла closed beta своей реализации draft-ietf-ipsecme-ikev2-mlkem — её выкатили в production в IPsec-сервисе и тестировали против эталонной реализации strongSwan (популярный open-source IPsec-стек для Linux). Теперь, после GA, подтверждена совместимость с другими вендорами:
- Cisco: клиенты Cisco 8000 Series Secure Routers с прошивкой 26.1.1 и выше могут поднять post-quantum Cloudflare IPsec туннели по draft-ietf-ipsecme-ikev2-mlkem.
- Fortinet: клиенты Fortinet FortiOS 7.6.6 и выше могут поднять post-quantum Cloudflare IPsec туннели до глобальной сети Cloudflare по тому же draft.
Почему совместимость важна (и почему это болит)
Обновить криптографию — задача на годы. Цель Cloudflare 2029 требует концентрированной работы. Поэтому компания надеется, что IPsec-сообщество продолжит фокусироваться на разработке совместимых стандартов вроде draft-ietf-ipsecme-ikev2-mlkem.
Важность стандартов проще понять на сравнении с TLS. Полная спецификация hybrid ML-KEM для IPsec, draft-ietf-ipsecme-ikev2-mlkem, стала доступна только в конце 2025 года. Это примерно на четыре года позже, чем поддержка hybrid ML-KEM появилась в TLS. (Cloudflare включила hybrid post-quantum key agreement для TLS ещё в 2022, до того как NIST окончательно утвердил стандартизацию ML-KEM, — потому что TLS-сообщество быстро сошлось на одном совместимом подходе и продавило его в production. Сегодня более двух третей человеко-генерированного TLS-трафика к сети Cloudflare защищены hybrid ML-KEM.)
Четырёхлетнее отставание частично объясняется тем, что IPsec-сообщество долго присматривалось к Quantum Key Distribution (QKD). Механизм её интеграции в IKEv2 (Internet Key Exchange version 2 — протокол согласования ключей IPsec) описан в RFC 8784, опубликованном в 2020 (сам RFC посвящён подмешиванию pre-shared keys в IKEv2 — а такие ключи могут поставляться, в частности, через QKD). Cloudflare уже писала, почему QKD не входит в их post-quantum стратегию: для QKD нужны специализированные устройства и выделенный физический канал между двумя сторонами — а это значит, что в масштабах интернета QKD не работает. Плюс QKD не решает задачу аутентификации, поэтому post-quantum криптография всё равно нужна, чтобы остановить активных атакующих. Найти реализации QKD, которые совместимы между разными вендорами, тоже сложно.
Американская NSA (National Security Agency), немецкая BSI (Bundesamt für Sicherheit in der Informationstechnik) и британская NCSC (National Cyber Security Centre) — все три национальные службы информбезопасности — предупреждают: нельзя полагаться только на QKD. Post-quantum криптография, в свою очередь, работает на железе, которое у вас и так есть, аутентифицирует обе стороны и работает end-to-end через интернет.
RFC 9370 и ciphersuite bloat
RFC 9370, опубликованный в 2023, открыл двери post-quantum криптографии в IPsec — он разрешил параллельно с классическим Diffie-Hellman прогонять до семи дополнительных обменов ключами. Однако RFC 9370 не указал, какие именно ciphersuite (наборы криптографических алгоритмов) должны использоваться в этих параллельных обменах. В отсутствие такой спецификации часть вендоров выпустила ранние реализации на базе RFC 9370 ещё до того, как появился draft hybrid ML-KEM, — и определили собственные ciphersuite, в том числе не стандартизированные NIST. Это ровно тот «ciphersuite bloat», от которого предостерегал NIST в SP 800-52 r2. И риск для совместимости проявился на практике: Cloudflare IPsec пока не взаимодействует с реализацией Palo Alto Networks по RFC 9370, потому что та была запущена до появления draft-ietf-ipsecme-ikev2-mlkem.
Хорошая новость в том, что теперь у нас есть draft-ietf-ipsecme-ikev2-mlkem, который заполняет пробелы RFC 9370 — явно прописывая hybrid ML-KEM как один из механизмов согласования ключей, который можно гонять параллельно с классическим Diffie-Hellman. Cloudflare надеется добавить Palo Alto Networks в список совместимых post-quantum branch-коннекторов по мере того, как индустрия будет консолидироваться вокруг draft-ietf-ipsecme-ikev2-mlkem.
Но путь к совместимым post-quantum IPsec-стандартам ещё не пройден. draft-ietf-ipsecme-ikev2-mlkem закрывает шифрование. Но IPsec нужны стандарты для post-quantum аутентификации — иначе после Q-Day атакующие смогут проводить активные атаки на живые системы (подменять стороны handshake), даже если шифрование стоит. Cloudflare надеется, что IPsec-сообщество сосредоточится на совместимых PQC-реализациях, а не уходит в нишевые сценарии с QKD.
Зачем это всё клиентам Cloudflare
Cloudflare обещает не брать с клиентов отдельных денег за post-quantum: фича включена в существующие тарифы IPsec и не требует обновления железа на стороне клиента — нужны только свежие прошивки Cisco/Fortinet и поддержанная их сторона.
В TLS-мире уже больше двух третей человеко-генерированного трафика к сети Cloudflare идёт через post-quantum шифрование. В мире site-to-site IPsec до этого момента всё было иначе.
FAQ
Что мне делать, если я не клиент Cloudflare?
Та же тема обсуждается в IETF, и вендоры (Cisco, Fortinet, strongswan) внедряют draft-ietf-ipsecme-ikev2-mlkem на своей стороне независимо от Cloudflare. Если у вас IPsec-туннели между двумя своими сайтами — следите за релизами своих branch-коннекторов и временем, когда появится поддержка post-quantum IKEv2. Главное — не идти по пути собственных ciphersuite на базе RFC 9370 до того, как стандарт окончательно стабилизируется; это создаёт ту самую проблему совместимости, которая сейчас обсуждается.
Что такое Q-Day и насколько он близко?
Q-Day — условный момент, когда появятся квантовые компьютеры, способные сломать классическую public-key криптографию (RSA, ECDH, ECDSA). Точную дату никто не знает: оценки сдвигаются, и Cloudflare как раз ускорила свой target до 2029 после недавних прорывов в квантовом железе. Принципиально важно, что для harvest-now-decrypt-later атак Q-Day будущего применяется к трафику настоящего — поэтому защищаться нужно сейчас, не «когда квантовые компьютеры появятся».
Чем hybrid отличается от чистого post-quantum?
Hybrid означает, что в handshake одновременно работают два механизма согласования ключей: классический (Diffie-Hellman) и post-quantum (ML-KEM). Если в ближайшие годы кто-то найдёт атаку на ML-KEM (а это пока относительно молодой алгоритм, по стандартам криптографии), классический Diffie-Hellman всё ещё будет защищать соединение. И наоборот: если квантовый компьютер сломает Diffie-Hellman, останется ML-KEM. Поэтому индустрия не делает чистый post-quantum в ближайшие годы — слишком велик риск, что новый алгоритм окажется слабым.
Почему QKD не подходит, если о ней так много говорят?
Quantum Key Distribution (QKD) — это распределение ключей через физические свойства фотонов на специальном оптическом канале. Технически интересно, но требует выделенного оптоволокна между конкретной парой устройств и специализированных коробок на концах канала. В масштабах интернета такое не масштабируется. Плюс QKD не аутентифицирует стороны — без post-quantum криптографии злоумышленник в середине всё равно может подменить собеседника. Поэтому NSA, BSI и NCSC прямо предупреждают: только QKD недостаточно.
Что post-quantum ML-KEM ещё не защищает в IPsec?
Аутентификацию. Сейчас draft-ietf-ipsecme-ikev2-mlkem закрывает только согласование ключей и шифрование. Подписи (как обе стороны IPsec удостоверяют свою личность друг другу) до сих пор делаются классическими алгоритмами. После Q-Day атакующий с квантовым компьютером сможет подделывать такие подписи и проводить активные MitM-атаки — даже если данные зашифрованы hybrid ML-KEM. IETF работает над post-quantum подписями (NIST уже стандартизировал ML-DSA и SLH-DSA), но в IPsec эти стандарты ещё впереди.
Что делать сегодня
Если у вас Cloudflare IPsec и Cisco 8000/Fortinet FortiGate в филиале, начните с чек-листа: версия прошивки (Cisco 26.1.1+, FortiOS 7.6.6+), включить параметр post-quantum hybrid в конфигурации IKEv2-туннеля, проверить логи на успешный обмен ML-KEM. Если у вас Palo Alto Networks или другой вендор, который пока запускает RFC 9370 без draft-ietf-ipsecme-ikev2-mlkem, — следить нужно за обновлениями прошивок самого вендора (Palo Alto обещает присоединиться к draft, как только индустрия консолидируется). До этого момента катить ранний vendor-specific вариант не стоит — легко получить туннели, которые не поднимаются между разными вендорами.
Оригинальный пост Sharon Goldberg и Amos Paul — на blog.cloudflare.com. Спецификация: draft-ietf-ipsecme-ikev2-mlkem на datatracker.ietf.org. Стандарт ML-KEM: FIPS 203 на csrc.nist.gov.
