Cloudflare 将其源站 TLS 握手过程中的静态假设替换为针对每个源站的实际测量值，从而将扫描到的源站中的 HelloRetryRequests 比例从约 52% 降至 3.7%，并将 p90 握手延迟缩短了 150 多毫秒。
被替换掉的假设已经沿用多年。TLS 1.3 要求客户端在第一个数据包中就确定密钥协商算法，而此时服务器尚未声明其支持的算法。如果猜测正确，那么握手过程仅需一次往返即可完成；如果猜测错误，那么源站将返回一个 HelloRetryRequest，客户端需要发送第二个 ClientHello，这时就需要两次往返才能建立连接。
Cloudflare 基于“超过 95% 的源站支持 X25519”这一合理依据，默认互联网上的每个源站都使用 X25519。测量结果表明，对于大约 30% 的源站连接，这种猜测并非最优方案。超过 6% 的源站更倾向于使用 P-256 或 P-384 而非 X25519。这就意味着这些连接完全出于传统原因而多消耗了一次往返。
作为自动 SSL/TLS 的扩展功能，自动密钥交换（Automatic Key Exchange）会探测每个源站，以便了解其支持和偏好的算法，然后优先使用该算法。如果源站能够处理后量子混合算法 X25519MLKEM768，那么 Cloudflare 会优先选用该算法。探测操作在生产流量路径之外进行，每次处理一组密钥协商，并且每天会重新扫描源站，以便偏好设置能跟上负载均衡器和 TLS 库的变化。该功能在当前所有的区域里都已经启用，并且在新区域中默认启用。用户可以在控制台的 SSL/TLS 部分进行开关设置，而 Cloudflare 会在整个区域内应用同一偏好设置。
测量结果揭示的信息比观察所获得的信息更为丰富。根据 Cloudflare 的报告，主动探测发现了数千个源站，它们在被动流量中从未显示出对后量子加密算法的支持，因为许多源站即使支持更强的加密方案，也会直接接受经典密钥共享，而不会发出重试请求。
这次变更中涉及后量子加密的部分存在一个值得了解一下的限制。X25519MLKEM768 密钥共享的长度为 1216 字节，而 X25519 仅为 32 字节，这会导致 ClientHello 消息超出单个网络数据包的容量。虽然 TLS 标准允许多数据包分段传输，但当 ClientHello 被拆分为多个 TCP 分段时，某些老旧的中间设备（middleboxes）和源站就会出现处理失败的情况。在 Cloudflare 早先的一项研究中，约 0.34% 的被扫描源站在收到优先携带后量子密钥共享时，无法完成握手过程。
正因如此，Cloudflare 自 2023 年 9 月起便将 HelloRetryRequest 作为安全阀使用：虽然宣传支持后量子加密，但仍然以经典的 X25519 作为默认方案，并要求具备后量子加密能力的源站通过重试请求来发起升级。其结果就是，几乎每次后量子源站握手都不得不进行强制性的第二次往返通信。
引入这一变化的依据是采用率数据。源站对后量子密钥交换的支持率已从 2023 年的 0.5% 增长到如今的 12.8%。也就是说，大约八分之七的源站仍然无法使用该功能。在 Cloudflare 迄今为止扫描过的样本中，有 64% 仍然使用经典的 X25519，而且连接配置未作任何更改，有 33% 迁移到了 X25519MLKEM768，还有 3% 迁移到了其他经典算法，例如 P-384、P-256 或 P-521。
对于能够使用后量子密钥交换的源站，往返开销现在已经基本消除。不需要 HelloRetryRequest 的后量子源站 TLS 1.3 流量占比从 0% 上升至 99.2%。在扫描的样本中，后量子源站流量从每天约 250 亿次连接增长至 450 亿次。Cloudflare 认为，这部分归因于“自动密钥交换”功能对传统加密连接的升级改造。
有一项新的“合规要求”设置所带来的风险值得警惕。该设置会过滤 Cloudflare 可协商的密钥协议，提供“仅限后量子混合模式”和“仅限符合 FIPS 标准的算法”两种选项。这实际上是限制了 Cloudflare 可以使用的选项，而非为源站赋予了新功能。因此，如果强制不支持 X25519MLKEM768 的源站使用后量子混合模式，将导致双方没有任何共同支持的算法，所有指向该源站的 TLS 1.3 连接都会失败。如果没有算法同时满足两项要求，就无法同时选中这两个选项。这些设置仅适用于 TLS 1.3 连接。
已部署自动化功能的团队应该注意一项较为低调的变更。源站后量子加密 API 仍然可以使用，但针对该 API 的请求现在已成为无操作（no-ops），不会改变一个区域的后量子密钥协商行为。Cloudflare 表示，他们计划弃用该 API，但尚没有给出具体日期。你可以通过 BoringSSL 的 bssl 客户端工具直接向 443 端口发起源站检测，确认协商出的加密算法是否为 X25519MLKEM768。
这次部署采用的机制比较保守。新配置将首先应用于一小部分源站流量，系统会监控针对该源站的失败率和重试率，并与基准值进行对比。如果重试率上升，则会回滚该变更——这与 Automatic SSL/TLS 在加密模式升级出现异常时采用的模式相同。Cloudflare 指出，回滚的最坏情况只是增加一次往返，而非导致连接中断。
对于评估该功能收益的团队而言，有两点限制值得注意。延迟改善仅适用于新建立的连接，现有长连接（keep-alive）上的请求完全不受影响；而且，收益主要集中在动态请求以及需要重新进行源站握手操作的 CDN 缓存未命中场景中。此外，当源站不支持后量子密钥交换时，自动密钥交换功能将无法优先采用该方案，尽管 Cloudflare 表示该功能仍然可以通过学习源站偏好的经典算法来发挥作用。
密钥协商只是问题的一半。虽然它能保护当前的流量免遭未来解密，但无法阻止拥有量子计算机的攻击者伪造经典证书并冒充源站身份。自 2026 年年中起，Cloudflare 已经在“经过身份验证的源站拉取”和“自定义源站信任存储库”中支持 ML-DSA 后量子签名。现在，这两项功能结合使用已经能够实现对源站的端到端后量子身份验证。文档警告称，除非验证方拒绝接受经典证书，否则部署 ML-DSA 证书毫无意义——因为攻击者一旦获取了经典密钥，依然可以冒充通信对端进行身份伪造。
他们的路线图上列出了三项内容。由于偏好设置是按区域来定的，所以一个性能滞后的源站可能会拖慢整个区域的进度，而 Cloudflare 计划按源站进行精细化管理。通过对控制台和 API 进行按需扫描，使运维人员在升级 TLS 栈后能够立即触发重新评估，而无需等待下一次每日扫描。此外，该公司还计划扩展扫描功能，自动检测 ML-DSA 支持情况，并为需要严格保护的客户禁用经典加密的回退机制。
Cloudflare 对这项工作的定位是应对 2029 年的“ Q 日”——业内部分评估认为，经典加密算法可能在这一年被破解。同时，该工作也是为了应对“先采集、后解密”攻击，即攻击者将记录的流量存储起来以便日后解密。BoringSSL、OpenSSL 和 rustls 的最新版本已经包含后量子加密支持，而企业源站技术栈、云负载均衡器和嵌入式 TLS 终结器则在按各自的时间表进行升级。
原文链接：https://www.infoq.com/news/2026/09/cloudflare-automatic-key-exchang/
