Cloudflare 宣布扩展 Automatic SSL/TLS 服务，推出 Automatic Key Exchange 功能。该功能会在实际连接前了解客户源站服务器的能力，然后在首次尝试时选择合适的密钥交换算法。当源站服务器和网络路径能够使用时，该功能优先选择具备抗量子计算能力的混合算法 X25519MLKEM768。
该功能针对的是 Cloudflare 基础设施与源站服务器之间建立的第二条连接，而不是用户与平台之间的连接。由于 TLS 1.3 要求客户端在第一条消息中发送密钥交换算法，Cloudflare 此前必须使用固定猜测值 X25519。如果服务器偏好其他算法，就会发送 HelloRetryRequest，导致握手重新开始，并增加一个完整的网络往返时延。
从猜测转向测量
Cloudflare 会在生产流量路径之外进行一系列轻量级 TLS 握手，在每次测试中分别提供 X25519、P-256、P-384、P-521 或 X25519MLKEM768 中的一种算法。平台利用测试结果确定每个源站支持的算法，并独立评估各个子域名，同时根据每个子域名的实际流量规模对结果进行加权。
随后，平台会按照从后量子混合算法开始的顺序，选择可用性最高的选项；如果源站不接受该算法，则退回到源站支持的速度更快的经典算法。Cloudflare 会先将这一变更逐步应用于源站的一小部分流量，监控失败率和 HelloRetryRequest 请求，并在性能超过基线时回退配置。平台还会每天重新检查源站，以跟踪负载均衡器、TLS 库或服务器设置的变化。
公布的性能与安全影响
Cloudflare 称，在纳入测量的源站中，HelloRetryRequest 请求率已从约 52% 降至 3.7%，并在第 90 百分位将握手时延降低了超过 150 毫秒。这一影响尤其体现在需要与源站建立新连接的请求中，例如动态请求或 CDN 缓存未命中的情况；而通过 keep-alive 建立的现有连接不需要重新握手。
据该公司称，在接受检查的集合中，99.2% 的后量子 TLS 1.3 连接能够在一个往返周期内完成。此外，采用后量子密钥交换的源站流量规模已从每天约 250 亿次连接增加到 450 亿次连接，同时数十万个域名无需人工干预便获得了这项保护。Cloudflare 表示，在首批超过 100 万个域名中，33% 被选择使用 X25519MLKEM768，64% 仍使用 X25519，3% 使用其他经典算法。
这对客户实际上有什么变化？
对于使用支持 TLS 1.3 的源站的新域名和现有域名，该功能默认启用。用户可以在 Cloudflare 控制面板的 SSL/TLS，然后进入 Origin connection & post-quantum encryption 页面进行控制。如果源站不支持 X25519MLKEM768，该功能不会自动为其增加这种能力，但可以选择兼容的经典算法，避免不必要的重新握手。
Cloudflare 还提供两项合规设置：将协商限制为后量子混合交换，或将其限制为符合 FIPS 的算法。不过，在不支持后量子交换的源站上启用该功能，可能导致所有 TLS 1.3 连接失败，因此公司警告不要在事先未验证的情况下使用这一选项。Cloudflare Radar 提供检查服务器和网络路径处理此类连接能力的功能，其中包括防火墙、中间系统和分片消息带来的问题。
为什么这一公告很重要？
这一变化将直接的性能改进与扩大后量子加密采用的尝试结合起来，同时无需网站运营者手动指定算法。但它无法替代源站服务器或负载均衡器的升级；平台无法协商服务器不支持的算法。此外，后量子密钥交换能够防范记录加密数据并在日后解密的场景，但无法单独解决源站身份冒充或认证降级风险。Cloudflare 表示，下一步包括检查对 ML-DSA 证书的支持，并在具备严格的后量子保护时阻止回退到经典证书。