在 2025 年 Security Week 期间，Cloudflare 推出了业界首个云原生后量子安全 Web 网关 (SWG) 和 Zero Trust 解决方案，这是保护企业网络流量（从最终用户设备发送到公共和专用网络）安全的重要一步。
但这只是问题的一部分。若要真正保护企业网络的未来安全，需要完整的安全访问服务边缘 (SASE)。
今天，我们完善了问题的另一面：Cloudflare One 是首个在安全 Web 网关以及 Zero Trust 和广域网 (WAN) 用例中支持符合现代后量子 (PQ) 加密标准的 SASE 平台。更具体地说，Cloudflare One 现在在所有主要入口和出口提供后量子混合型基于模块晶格的密钥封装机制 (ML-KEM)。
为了完善解决方案，我们增加了对 Cloudflare IPsec（云原生 WAN 即服务）和 Cloudflare One Appliance（用于建立 Cloudflare IPsec 连接的物理或虚拟 WAN 设备）对后量子加密的支持。Cloudflare IPsec 利用 IPsec 协议在客户网络与 Cloudflare 全球网络之间建立加密隧道，并使用 IP Anycast 自动将该隧道路由到最近的 Cloudflare 数据中心。Cloudflare IPsec 简化配置并提供高可用性；如果某个数据中心不可用，流量会自动重新路由到最近的正常运行的数据中心。Cloudflare IPsec 在我们的全球网络规模上运行，且支持跨 WAN 的站点间通信以及出站互联网连接。
随着版本 2026.2.0 的发布，Cloudflare One Appliance 升级版现已正式发布。Cloudflare IPsec 升级版则处于封闭测试阶段，您可以将自己的名字添加到我们的封闭测试列表，通过这种方式来申请访问权限。
量子威胁不是“下一个十年”要考虑的问题。以下是我们的客户当前优先考虑后量子加密技术 (PQC) 的原因：
最后期限日益临近。2024 年底，美国国家标准与技术研究院 (NIST) 发出了明确信号（其他机构也纷纷响应）：使用经典公钥密码技术的时代即将结束。根据 NIST 的规划，2030 年是淘汰 RSA 和椭圆曲线加密 (ECC) 并过渡到强大的量子计算机无法破解的 PQC 的最后期限。随着最后期限的临近，尚未开始迁移的企业将面临不合规和易受攻击的风险。
升级历来都是一个棘手的问题。2030 年似乎看似遥远，但升级加密算法的难度众所周知。历史经验表明，密码技术的弃用淘汰可能需要数十年时间：例如，我们发现 MD5 在被弃用 20 年之后仍然会造成问题。主要的瓶颈在于缺乏加密敏捷性（即：轻松切换加密算法的能力）。将后量子加密直接集成到我们的 SASE 平台，也就是 Cloudflare One 中，不仅会提供内置的加密敏捷性，而且可简化企业提供远程访问和站点间连接的方式。
数据可能已经面临风险。最后，“先收集、后解密”是一种持续存在的现实威胁，它是指攻击者当下收集敏感的网络流量，然后将其存储，直到量子计算机具备足够的能力进行解密。如果您的数据保存期限超过几年（例如财务信息、健康数据、国家机密），除非使用后量子加密进行保护，否则此类数据已经面临风险。
将网络流量过渡到后量子加密 (PQC) 需要对两种加密源语进行彻底修改：也就是密钥协商与数字签名。
迁移 1：密钥建立。密钥协商让双方通过不安全的通道建立共享密钥；然后使用该共享密钥来加密网络流量，从而实现后量子加密。业界已基本趋向于采用基于模块晶格的密钥封装机制 (ML-KEM) 作为标准的后量子密钥协商协议。
ML-KEM 已广泛应用于 TLS，它通常与经典的 Elliptic Curve Diffie Hellman (ECDHE) 搭配使用，其中用于加密网络流量的密钥是通过混合 ML-KEM 与 ECDHE 密钥协商的输出结果而生成。（这也被称为“混合型 ML-KEM”。）目前，流向 Cloudflare 网络的超过 60% 真人用户生成的 TLS 流量均受到混合型 ML-KEM 的保护。向混合型 ML-KEM 的过渡之所以成功，是因为它：
由于 ML-KEM 与经典的 ECDHE 并行运行，因此，与经典的 ECDHE 方法相比，其安全性和合规性没有降低。
迁移 2：数字签名。同时，数字签名和证书可以保护真实性，阻止活跃的对手假冒服务器来诱骗客户端。遗憾的是，与传统的 ECC 算法相比，目前的后量子签名体积更大，这减缓了其普及速度。幸运的是，迁移到后量子签名并不那么紧迫，因为后量子签名旨在阻止拥有强大量子计算机的对手，而这种计算机目前尚未问世。因此，虽然 Cloudflare 积极致力于后量子数字签名的标准化和推广，但当前的 Cloudflare IPsec 升级重点在于将密钥建立机制升级为混合型 ML-KEM。
美国网络安全和基础设施安全局 (CISA) 在其 2026 年 1 月发布的出版物《使用后量子加密标准的技术产品类别》中，认可了这两种迁移的性质。
为了实现完全受后量子加密保护的 SASE，我们升级了 Cloudflare IPsec 产品，以支持 IPsec 协议中的混合型 ML-KEM。
IPsec 社区实现后量子加密的历程与 TLS 截然不同。TLS 是加密第 4 层公共互联网流量（例如，从浏览器到内容分发网络 (CDN)）的事实标准，因此，安全性和供应商互操作性是其设计的重中之重。同时，IPsec 是一种第 3 层协议，通常用于连接由同一供应商生产的设备（例如，两个路由器），因此，互操作性历来都不是其关注的重点。考虑到这一点，让我们来看看 IPsec 迈向量子未来的历程。
2020 年 5 月发布的 RFC 8784 旨在成为 IPsec 互联网密钥交换协议第 2 版 (IKEv2) 的后量子更新版本，IKEv2 用于建立对称密钥以加密 IPsec 网络流量。RFC 8784 暗示可以使用长期的预共享密钥 (PSK) 或量子密钥分发 (QKD)。但这两种方法都不太令人满意。
RFC 8784 建议混合使用 PSK 与源自 Diffie Hellman Exchange (DHE) 的密钥，本质上来说是将 PSK 与 DHE 相结合。这种方法可以抵御“先收集、后解密”型攻击者，但无法提供前向保密以防范量子对手。
前向保密是密钥协商协议的一个标准必要条件。它可确保即使是在泄露了长期密钥的情况下，系统也是安全的。RFC 8784 中的 PSK 方法容易受到“先收集、后解密”型攻击者，这种攻击也获得一个长期 PSK 的副本，然后在未来强大的量子计算机面世后，通过破坏 DHE 密钥协商来解密流量。
为了解决前向保密问题，反而可以使用 RFC 8784 来混合经典的 DHE 密钥与根据量子密钥分发 (QKD) 协议新生成的密钥。
QKD 利用量子力学，在双方之间建立共享的私密加密密钥。重要的是，为了让 QKD 正常发挥作用，双方必须拥有专用的硬件或通过专用的物理连接设备进行连接。这个重大限制导致 QKD 无法用于常见的互联网用例，例如，通过 Wi-Fi 将笔记本电脑连接到远程服务器。正是由于种种限制，我们从未投资为 Cloudflare IPsec 部署 QKD。美国国家安全局 (NSA)、德国联邦信息安全局 (BSI) 和英国国家网络安全中心也警告，不要完全依赖 QKD。
2023 年 5 月发布的 RFC 9370 规定使用混合型密钥协商，而不是 PSK 或 QKD。但是，不同于 TLS（它只支持搭配使用后量子 ML-KEM 与经典的 DHE，此项 IPsec 标准支持最多使用七种不同的密钥协商，同时与经典的 Diffie Helman 并行运行。此外，它没有具体说明这些密钥协商的细节，而是让供应商自行选择其算法和实施方案。例如，Palo Alto Networks 高度重视这个问题，在其下一代防火墙 (NGFW) 中内置了对超过七种不同后量子密码套件的支持，其中大多数无法与其他供应商进行互操作，有些甚至尚未实现 NIST 标准化。
多年来，TLS 的发展趋势恰恰相反，注册的密码套件数量从 TLS 1.2 的数百个减少到 TLS 1.3 的大约五个。这种减少“密码套件臃肿”的理念也符合 NIST 2019 年发布的 SP 800 52。减少“密码套件臃肿”的理由包括：
提高不同供应商和跨区域的互操作性
降低利用降级到弱密码套件发起攻击的风险
降低因配置错误而导致安全问题的风险
通过减少代码库大小，降低实施缺陷的风险
这就是我们最初没有构建 RFC 9370 支持的原因。
这也是我们对 IPsec 社区提出 draft-ietf-ipsecme-ikev2-mlkem 感到兴奋的原因。这份互联网草案实现了 IPsec 后量子密钥交换的标准化，与 TLS 广泛部署的后量子密钥交换相同：混合型 ML-KEM。新草案填补了 RFC 9370 的空白，指定如何在 IKEv2 中将 ML-KEM 作为附加密钥交换与经典的 Diffie Hellman 并行运行。
鉴于此规范现已发布，我们已着手在 Cloudflare IPsec 产品中支持后量子 IPsec。
Cloudflare IPsec 是一种 WAN 网络即服务解决方案，通过将数据中心、分支机构和云 VPC 连接到 Cloudflare 的全球 IP Anycast 网络，它取代了传统的专用网络架构。
使用 Cloudflare IPsec，Cloudflare 网络充当 IKEv2 响应方，等待来自 IPsec 发起方（即：客户网络中的分支连接器设备）的连接请求。Cloudflare IPsec 支持由分支连接器发起的 IPsec 会话，这些分支连接器包括 Cloudflare 推出的 Cloudflare One Appliance，以及 Cisco、Juniper、Palo Alto Networks、Fortinet、Aruba 等其他不同供应商的连接器。
我们已经在 Cloudflare IPsec IKEv2 响应方中实施了生产环境混合型 ML-KEM 支持，如 draft-ietf-ipsecme-ikev2-mlkem 中的指定。该草案要求首先使用经典的 Diffie Helman 密钥交换来进行第一次密钥交换。派生的密钥用于加密使用 ML-KEM 密钥交换进行的第二次密钥交换。最后，将两次交换生成的密钥混合在一起，并将结果用于保护 IPsec ESP（封装安全有效负载）模式下的数据平面流量。ESP 模式使用对称加密技术，因此，无需任何额外升级即可保证量子安全。我们已使用 strongswan 参考实施中的 IPsec 发起方测试了我们的实施。
您可以通过查看 Cloudflare IPsec 日志，了解 IKEv2 协商中使用的密码套件。
我们选择实施混合型 ML-KEM，而不是纯 ML-KEM（即：仅使用 ML-KEM 而不并行运行 DHE），原因有两个。其一，我们在所有其他 Cloudflare 产品中都采用了混合型 ML-KEM，因为这是 TLS 社区普遍采用的密钥交换方法。其二，它提供了一种“双保险”的安全保障：ML-KEM 可以抵御“先收集、后解密”型量子攻击，而 DHE 则提供久经考验的算法来防范非量子对手。
只有支持互操作性，才能充分利用实施的价值。为此，我们邀请其他根据 draft-ietf-ipsecme-ikev2-mlkem 正在其分支连接器中构建 IPsec 发起方支持的供应商，针对我们的 Cloudflare IPsec 实施进行测试。希望在我们进行封闭测试期间参加与第三方分支连接器互操作性测试的 Cloudflare 客户可以在此处注册。我们计划正式发布并构建与其他供应商的互操作性，随着更多供应商开始支持 draft-ietf-ipsecme-ikev2-mlkem，互操作性将逐步提高。
量子安全硬件：Cloudflare One Appliance
我们的许多客户从 Cloudflare 购买分支连接器（硬件或虚拟化），而不是从第三方供应商购买。因此，我们用于将本地网络连接到 Cloudflare One 的即插即用型设备 Cloudflare One Appliance 也升级了功能，可以支持后量子加密。
Cloudflare One Appliance 不使用 IKEv2 进行密钥协商或会话建立，而是选择依赖 TLS。设备会定期发起与 Cloudflare 边缘节点的 TLS 握手，通过生成的 TLS 连接来共享对称密钥，然后将该对称密钥注入 IPsec 的 ESP 层，ESP 层随后对 IPsec 数据平面流量进行加密和身份验证。这种设计使我们能够避免构建 IKEv2 发起方逻辑，以及利用现有的 TLS 库简化连接器的维护。
因此，将 Cloudflare One Appliance 升级到支持后量子加密，就像将 TLS 1.2 升级到采用混合型 ML-KEM 的 TLS 1.3 一样，Cloudflare 的不同产品已经多次完成过类似的升级。
与以往一样，我们的客户可以免费升级到 Cloudflare IPsec。我们认为，安全且私密的互联网应该惠及所有人，因此，我们致力于将后量子加密集成到所有 Cloudflare 产品，无需任何专用硬件，也无需客户和最终用户支付任何额外费用。
使用 Cloudflare One Appliance 的客户通过 2026 年 2 月 11 日发布的版本 2026.2.0 获得了后量子加密升级。升级是根据每台设备配置的中断窗口自动推送（无需客户操作）。
对于使用 Cloudflare IPsec 并搭配其他供应商生产的分支连接器设备的客户，随着更多供应商开始支持 draft-ietf-ipsecme-ikev2-mlkem，我们将实现与这些连接器的互操作。您也可以直接联系我们，获取参加封闭测试的权限，并要求我们与特定供应商的分支连接器实现互操作。
后量子 SASE 的价值主张非常明确：企业通过混合型 ML-KEM 保护的隧道发送专用网络流量，从而获得即时的端到端保护。这可以保护流量免受“先收集、后解密”型攻击，即使企业网络中的单个应用尚未升级到支持 PQC 也是如此。
上图显示了如何在各种 Cloudflare One 网络配置中提供后量子混合型 ML-KEM。它包括以下入口：
以及以下出口：
下图着重展示了一个示例网络配置，它使用 Cloudflare One Client 入口将设备连接到 Cloudflare One Appliance 出口后面的服务器。最终用户的设备使用 MASQUE 搭配混合型 ML-KEM 连接到 Cloudflare 网络（链路 1）。然后，流量通过 TLS 1.3 搭配混合型 ML-KEM 隧道，在 Cloudflare 全球网络中传输（链路 2）。然后，流量通过后量子加密 Cloudflare IPsec 链路（链路 3）离开 Cloudflare 网络，最终到达一台 Cloudflare One Appliance。最后，流量连接到客户环境中的一台服务器。如此一来，即使服务器本身不支持后量子加密技术，流量在公共互联网中传输时也会受到后量子加密的保护。
最后，我们发现，先进入 Cloudflare One 然后输出到公共互联网的流量，也可以通过我们支持后量子加密的 Cloudflare Gateway，也就是安全 Web 网关 (SWG) 进行保护。下图显示了 SWG 的工作原理：
正如之前的一篇博客文章所述，我们的 SWG 已经可以支持使用混合型 ML-KEM 来加密从 SWG 到源服务器的流量（前提是源服务器支持混合型 ML-KEM），以及从客户端到 SWG 的流量（前提是客户端支持混合型 ML-KEM，大多数现代浏览器均支持）。重要的是，任何通过已安装 Cloudflare One Client 的设备进入 SWG 的流量仍将受到混合型 ML-KEM 的保护，即使 Web 浏览器本身尚不支持后量子加密技术。这是因为 Cloudflare One Client 会建立一条后量子加密的 MASQUE 隧道连接到 Cloudflare 全球网络。通过后量子 Cloudflare IPsec 隧道进入 SWG 的流量也是如此。
综上所述，Cloudflare One 现在在我们的 TLS、MASQUE 和 IPsec 入口/出口提供后量子加密，适用于专用网络流量，也适用于通过我们的 SWG 出口到公共互联网的流量。
通过将 Cloudflare IPsec 和 Cloudflare One 设备整合到后量子 SASE 协议中，我们已将后量子加密扩展到所有主要入口和出口。我们有意选择了互操作性和简单性的途径，即 IETF 以及 NIST 倡导的混合型 ML-KEM 方法，而不是让客户受困于专有实施、“密码套件臃肿”或不必要的硬件升级。
这就是 Cloudflare One 的承诺：提供的 SASE 平台不仅比它所取代的传统架构更快速、更可靠，而且还提供后量子加密功能。无论是保护远程办公人员的浏览器或是千兆数据中心链路，现在您都可以放心这些数据会受到保护，可以抵御“先收集、后解密”型攻击以及其他未来威胁。
在此处注册，获取关于 Cloudflare One SASE 平台后量子功能的完整演示；或者在此处注册，加入 Cloudflare IPsec 封闭测试列表。我们很荣幸能够引领行业迈入密码技术的新时代，并诚邀您与我们携手构建可扩展、符合安全标准的后量子互联网。