在TLS握手机制持续演进的背景下，Cloudflare通过替代静态假设、采用实际测量值的方式，显著优化握手性能，将HelloRetryRequests比例从约52%降至3.7%，同时使p90延迟缩短150多毫秒。核心逻辑在于，基于源站实际支持的算法进行动态调整：传统模型依赖假设，而实测发现约30%源站不采用最优的X25519方案，超6%源站选择P-256、P-384等算法，导致额外往返。自动密钥交换功能通过探测源站实际偏好动态适配，具备每日扫描与区域统一设置的特性。值得注意的是，后量子算法引入存在限制，如X25519MLKEM768的1216字节密钥长度超出数据包容量，可能引发中间设备处理失败，且已部署功能存在无操作风险。当前后量子支持率显著提升，约八分之七源站使用相关方案，但限制明显：无法同时满足全量子与经典加密合规要求，延迟改善仅适用于新建连接，无法覆盖长连接，其收益主要集中于特定场景。此外，功能升级存在潜在风险，包括偏好设置影响区域进度、密钥协议过滤限制安全性，以及后量子签名功能缺乏有效防护等，团队需密切关注相关影响与限制。
--91likeyou---
测量结果揭示的信息比观察所获得的信息更为丰富。根据 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 终结器则在按各自的时间表进行升级。
：
🔥 热词：#cloudflare 暴露源ip · #cloudflare验证测试 · #cloudflare ip检测 · #cloudflare隧道网速取决于什么 · #cloudflare原理 · #cloudflare 检查canvas算法 · #cloudflare验证三种模式 · #cloudflare在互联网中的位置