每次Cloudflare（Cloudflare）向源服务器建立TLS 1.3连接须先猜密钥协商算法，因首包就要定。猜对一次往返，错则源回复HelloRetryRequest重来需两次。多年全用X25519，对约30%连接非最优。今宣布自动密钥交换（Automatic Key Exchange）扩展自动SSL/TLS（Automatic SSL/TLS），以测量代猜，探得各源偏好算法首试即用，偏好后量子。

Cloudflare 每次向源站发起新的 TLS 1.3 连接时，必须在首发数据包中确定密钥协商算法，而此时源站尚未告知其支持情况。猜对则一次往返完成握手；猜错源站会回 HelloRetryRequest，需重新开始，耗费两次往返。

多年来我们对所有源站都默认猜 X25519。虽广泛支持，但后续测量发现对约 30% 的源站连接并非最优。

今天我们宣布 Automatic Key Exchange（自动密钥交换），作为 Automatic SSL/TLS 的扩展，用测量取代猜测。我们探测每个源站支持并偏好的算法，首次连接即使用该算法，只要源站支持后量子混合算法 X25519MLKEM768 就优先采用。

随着自动密钥交换逐步铺开，HelloRetryRequest 从约 52% 降至 3.7%，p90 握手延迟减少超 150 毫秒。此外，数十万域名已自动获得后量子源站连接，且每日递增。

延迟重要，但自动获得后量子连接更关键。当前已有攻击者记录暂不可解的加密流量，预期未来解密（即“先收割后解密”攻击）。Cloudflare 正冲刺在 2029 年（专家预估经典算法被破的那天，称 Q-Day）前实现互联网量子安全。这不能靠站长变密码学家，必须自动化。此前偏好后量子连接需手动设置，易出错；如今全自动。

TLS 1.3 握手：猜测密钥交换算法

每个安全网页连接始于 TLS 握手，用于认证服务器并派生共享密钥。先前博客已详述。

Cloudflare 作反向代理，看似一条安全连接实为两条：访客到 Cloudflare，以及 Cloudflare 到源站。各自独立握手、验证和加密。

自动密钥交换影响第二条连接。Cloudflare 连源站时作为 TLS 客户端发起握手，发送 ClientHello 消息，含主机名和支持的密钥协商算法列表。

理想情况下，TLS 1.3 仅需一次网络往返建立加密连接（上图左）。Cloudflare 发 ClientHello 列出算法及客户端密钥分享，源站接受则握手完成。这种预测性密钥交换是 TLS 1.3 创新，也是快于 1.2 的主因。

若源站偏好不同，会发 HelloRetryRequest（HRR）要求重试（上图右）。Cloudflare 发第二个 ClientHello 按源站指定算法生成新密钥分享。连接仍成功，但重试增加一次往返，类似马里奥赛车错过捷径。

无论哪种，服务器用客户端密钥分享生成共享密钥，并返回服务端密钥分享供客户端计算。该密钥用于 AES 等对称加密保护后续连接。

安全猜测的代价

多年来对 TLS 1.3 源站，我们静态猜测客户端密钥分享为 X25519，同时通告支持其他算法。这很安全，因为超 95% 源站支持 X25519，不支持的发 HRR 也不中断。

但 X25519 易受量子计算机攻击。自 2023 年 9 月，我们通告支持后量子密钥协商：先 X25519Kyber768Draft00，今为 X25519MLKEM768（标准版）。通告支持不同于在 ClientHello 中带头密钥分享。X25519MLKEM768 密钥分享 1216 字节，X25519 仅 32 字节，使 ClientHello 超出单包。虽标准允许多包，部分旧中间件和源站收到分片 ClientHello 会失败。此前研究约 0.34% 源站收到后量子密钥分享时握手失败，绝大多数仍用经典 X25519。

为防止连接中断，我们用 HRR 作安全阀：仅通告后量子支持，发经典 X25519 密钥分享，让有能力源站通过重试请求后量子交换。不支持 HRR 的源站客户可手动开启带头 X25519MLKEM768。2023 年至今，支持后量子密钥交换的源站从 0.5% 升至 12.8%，预计随托管栈升级继续增长。

此默认虽安全，但仅通过重试升级后量子带来不必要延迟，原因有二：

• 现代 OpenSSL、BoringSSL、rustls 均支持 X25519MLKEM768，但对经典 X25519 密钥分享处理不同：旧版默认接受除非显式优先后量子，新版立即发 HRR 优先后量子。
• 超 6% 源站偏好 P-256 或 P-384 而非 X25519，因我们静态选 X25519 导致即便纯经典连接也触发 HRR 往返。

为消除浪费的往返，我们作为 Automatic SSL/TLS 一部分扫描源站精确映射其密钥协商能力。依结果按源站定制初始密钥分享：最大化后量子连接且不致中断，同时加速适用域名。

将 Automatic SSL/TLS 延伸至后量子时代

Automatic SSL/TLS 现含自动密钥交换。面对百万源站，猜不同密钥分享有运营风险，因不知各自配置。我们直接测量而非推断，复用已有扫描管道。

对日益增多的源站，首次连接即达成后量子密钥协商，无额外往返，无需手动配置。

工作原理：

1. 对每个支持 TLS 1.3 的源站，我们发起几次轻量握手，每次仅提供一种密钥协商组：X25519、P-256、P-384、P-521 或 X25519MLKEM768。探测获知源站支持的全部算法。主动扫描在生产流量外进行，确认源站及中间网络能处理更强密钥协商后才用于真实流量。

2. 单域名常对应多子域名解析到不同源站。我们独立评估各子域名并按实际流量加权，使全域名偏好反映流量而非休眠子域等同繁忙端点。例如流量主要集中在 www 和 api，它们将主导全域名密钥交换偏好。

3. 从源站支持的组中按严格优先级选最强：后量子混合 X25519MLKEM768 优先，回退到源站接受的最快经典算法（X25519、P-256、P-384、P-521）。

4. 确定最优偏好后逐步灰度：先对小部分流量生效，监控失败和 HRR 率。若重试超基线则回滚，如同 Automatic SSL/TLS 回退异常加密模式。最坏情况仅多一次往返延迟，不会断连。

5. 源站配置随时变（换负载均衡、TLS 库升级带后量子、关旧算法）。我们每日重扫，新增或取消支持的在下次扫描更新偏好。

多数客户无需配置。若源站支持 TLS 1.3，我们自动协商其支持的最强密钥交换，例如支持 X25519MLKEM768 则优先，无额外往返达成后量子。

配置自动密钥交换

自动密钥交换默认开启，多数无需手动。如需可在 Cloudflare 面板 SSL/TLS > Overview > Configure > Origin connection & post-quantum encryption 独立管理。

开启后 Cloudflare 带外扫描源站并动态选密钥分享带头；关闭则停止扫描，回退静态默认顺序。

我们新增“合规要求”设置，可过滤允许 Cloudflare 用于源站连接的密钥协商：

• 后量子混合：仅限 X25519MLKEM768，彻底移除经典算法，保证所有成功源站 TLS 1.3 连接均后量子安全。
• 联邦信息处理标准（FIPS）：仅限 FIPS 合规密钥协商。

同时选两者需算法同时满足，无重叠则拒绝。详见文档。

选这些选项是指定意图而非具体算法，使合规演进或新后量子算法出现时配置自动保持最新。

但须谨慎，这些要求不赋予源站新能力，仅缩小协商范围。

重要提示：对不支持 X25519MLKEM768 的源站强制后量子混合将导致无共同算法，所有 TLS 1.3 连接失败。除非有严格策略义务，否则留空让自动密钥交换安全协商最优算法。

共同让互联网更安全更快

自动密钥交换适用于源站支持 TLS 1.3 的域名（预测偏好是 TLS 1.3 独有）。默认开启，扫描管道已为超百万域名分配偏好，其余持续接入。

初始群体中约 64% 仍偏好经典 X25519，连接无变；约 33% 设为 X25519MLKEM768，单次往返即抵御先收割后解密攻击；剩余 3% 选源站偏好的其他经典曲线如 P-384、P-256、P-521。

每日约 9000 域名密钥偏好被设为非 X25519 方法，几乎都直转后量子，其余采用源站更支持的其他经典曲线。

如前所述，自动密钥交换前因静态猜 X25519，几乎每个后量子源站握手都需 HRR，导致必须二次往返。

无 HRR 完成的后量子源站 TLS 1.3 流量占比从 0% 升至 99.2%。

随铺开，几乎全部后量子源站延迟惩罚消失：当前扫描群体中 99.2% 后量子 TLS 1.3 连接单次往返完成。此外该群体后量子源站流量从约 250 亿次增至每日 450 亿次，增长大部来自自动密钥交换将经典连接升级为后量子偏好。

许多源站支持多算法却不偏好某特定。例如支持后量子的源站可能仍接受经典 X25519 而不拒或发 HRR。被动观察无法揭示全部能力，主动探测让自动密钥交换发现了数千源站的后量子支持未在其流量中体现。

扫描器发现并更新偏好后，后量子连接迅即占这些源站流量绝大多数。其他经典算法占比很小，主因多源站混合部署。自动密钥交换不仅推动后量子，也帮源站匹配偏好经典曲线（非 X25519），降低整体 HRR 率。

启用前扫描域名约 52% 源站连接需 HRR，启用后仅 3.7%。避免 HRR 省去整次往返，p90 延迟降超 150 毫秒。这对动态请求和 CDN 未命中需新连源站尤为有益，降低用户延迟。已有 keep-alive 连接不需新握手故不受影响。

服务器是否支持后量子？

可用多种工具查服务器是否支持后量子密钥协商。我们提供 Cloudflare Radar 工具，输入主机名或 IP 即查是否支持后量子 TLS。注意若主机名经 Cloudflare 代理，Radar 查的是到 Cloudflare 的连接而非后方源站。

除验证算法支持，工具新增查后量子 TLS 实现缺陷。若结果负面会分析失败原因：常因旧中间件、防火墙或服务器缓存丢弃多包载荷或无法重组分片 ClientHello；或源站放弃无法识别密钥分享而非按 TLS 1.3 发 HRR，或发了却完不成握手。

Radar 清晰展示网络路径能否干净处理后量子流量。自动密钥交换不会切换未通过检查的源站域名，故清除这些问题才能实现升级。

若源站尚不支持后量子密钥协商？

即便源站今不支持后量子，开启自动密钥交换仍有益。它会探明支持项，若无 X25519MLKEM768 则用兼容经典算法，并学其偏好避免不必要 HRR。

但仅当源站已支持该算法时才能偏好后量子。当前全网超 12% 源站支持后量子。随着 BoringSSL、OpenSSL、rustls 新版支持，TLS 服务端实现中后量子算法支持在增加，企业栈、云负载均衡和嵌入式 TLS 终端按各自节奏升级。

若想为域名源站连接添后量子保护，有两选择：

• 用 Cloudflare Tunnel。cloudflared 与 Cloudflare 间已用后量子密钥协商，适用于无法改公网源站 TLS 软件时。
• 升级 TLS 端点。许多新框架和库默认启 X25519MLKEM768。但若曾手动配允许曲线，旧设可能覆盖默认。需审计所有终止或检查 TLS 的设备（负载均衡、WAF 等）确保启用该算法。托管服务可问提供商是否支持。

详见“Cloudflare 与源站间的后量子密码学”文档获取支持软件、配置示例和验证步骤。

下一步

自 2024 年公开构建 Automatic SSL/TLS。自动密钥交换是长路第二步而非终点。路线如图，具体在做的：

每个源站的偏好粒度

当前 Automatic SSL/TLS 在域名级决策，单源站行为可拖整域后腿。我们正做每子域/每源站粒度，使密钥协商和加密模式在服务于同域的多源站间不同。

按需扫描

若刚升级源站 TLS 栈，不应等下次计划扫描。我们构建按需重扫选项（面板或 API 触发），升级后即可立刻用更好密钥协商。

此外该扫描将作为诊断工具驻留面板，按需测源站行为，看清能协商哪些算法及失败原因（类似 Radar 外扫工具）。

自动后量子源站认证

后量子密钥协商防未来量子计算机解密今日流量，但不防攻击者用它伪造证书冒充源站。弥补需后量子认证，今年初 Authenticated Origin Pulls 和 Custom Origin Trust Store 已支持 ML-DSA 证书。

重要问题是降级攻击。假设源站同时支持经典 RSA/ECDSA 和新 ML-DSA 证书以兼容旧客户端。Q-Day 时活跃攻击者居间截握手悄丢后量子提议，Cloudflare 只见经典响应而回退验旧证，攻击者可量子伪造。

在广义 WebPKI 防降级复杂。提案之一 CA 在经典证书加后量子签名证其真不支持 PQ。虽公网可能如此，需时协调。更快（若可行）是彻底不信任经典证书。

源站连接能做到！我们计划扩展扫描检测源站后量子认证支持（ML-DSA 证书及未来 Merkle Tree 证书）。一旦识别，可为需严格保护的客户自动禁经典回退，消除降级风险且不扰未升级端点。

试试看

Cloudflare 相信强安全应免费、自动、默认开。Universal SSL 实现浏览器到 Cloudflare 默认加密，Automatic SSL/TLS 对 Cloudflare 到源站同理，现延伸至后量子密钥协商。

想看源站加密级别可查面板 SSL/TLS 区；想直验后量子准备度用 Radar 告知是否需更新栈；若已支持，自动密钥交换会告知 Cloudflare 从而更快更安全连源站。

社区对 Cloudflare 主动扫描源站以优化 TLS 握手往返的做法多持质疑与讽刺，认为其隐藏成本且显双标；少数人疑惑此看似明显的低垂果实为何此前未摘，另有讨论延伸至规模护城河与开源滞后。

认为主动扫描源站反而增加隐藏成本

• 指出 TLS 握手协商可能多往返，Cloudflare 每日存结果省可能延迟，但每个连接新增了绝对查找延迟与额外请求负担（较多人） > 他们节省了可能的往返延迟，却没说明现在每个连接都增加的绝对查找延迟（@sandeepkd）

讽刺 Cloudflare 行为双标且用户体验矛盾

• 省下握手毫秒却让用户等数十秒提示屏；一面抱怨大模型爬取负载充当卫士，一面自己发无用请求扫源站省微秒（较多人） > 周一抱怨大模型爬取压垮服务器，周二自己却发无用请求只为省首次连接的微秒（@greatgib）

疑惑此举为何现在才做

• 觉得在关键路径上此优化似明显低垂果实，推测必有更复杂原因（少数人） > 这看似关键路径上明显的低垂果实，为何他们之前没做呢？（@chrismorgan）

认为此优化彰显规模护城河

• 唯有巨大规模下才知道此类优化必要并能构建，小公司难察觉需求，规模渐成唯一防御（少数人） > Cloudflare 是为何不能随意拼凑基础设施的典型，这种优化只有到规模才显必要（@ttul）

担忧中间件吞噬新协议致开源滞后

• 中介抢先支持新协议密码套件，开源落后数年；独立者难抗资源鸿沟，用 CF 需交流量被中间人（少数人） > 有了 Cloudflare 就得交流量被中间人，可如今自己已无法轻松获得那些新协议（@LoganDark）

有价值的补充

• TLS 握手本身含无状态协商步骤，首猜算法失败会触发额外往返；Cloudflare 于生产流量外主动轻量握手探测源站与网络对强密钥协商的支持。
• h2o 曾是多年来唯一易得的 HTTP/3 服务端软件，折射开源实现滞后。