Cloudflare AKE 将源站 HelloRetryRequests 比例从 52% 降至 3.7%
Cloudflare 每次与源站建立新的 TLS 1.3 连接时，都必须做出一次预判：协议要求我们在发送的第一个数据包中提交密钥协商算法，而此时源站尚未向我们透露自身信息或其所支持的算法。若预判准确，握手过程只需一个往返即可完成。一旦预判失误，源站便会回复 HelloRetryRequest，导致连接流程重来，往返次数增加至两次。
过去多年来，我们对互联网上所有源站的预判策略保持一致：均采用 X25519。尽管该算法支持度极高，但后续测量数据显示，对于约 30% 的源站连接而言，这一选择并非最优。
今日，我们正式推出 Automatic Key Exchange。作为 Automatic SSL/TLS 的扩展功能，它通过实际测量取代了盲目猜测。我们探测每个源站，获取其支持及偏好的密钥协商算法，并在首次尝试时优先采用该算法，同时尽可能引导源站使用后量子混合算法 X25519MLKEM768。
随着 Automatic Key Exchange 在源站连接上的全面推广，HelloRetryRequests 占比从 52% 降至 3.7%，p90 握手延迟减少了 150 毫秒以上。此外，本次推广还使得数十万个域名直接启用了后量子源站连接，且这一数字每日都在增长，整个过程无需人工配置。
毫秒级的优化固然重要，但后者的影响可能更为深远。此时此刻，某个地方就有对手在记录那些他们暂时无法解密的加密流量，赌注是未来会破解成功（这种攻击方式被称为“先存后解”，harvest-now, decrypt-later）。Cloudflare 正全力冲刺，要在 2029 年让互联网具备抗量子攻击的安全性。多位行业专家估计，到那时传统加密算法可能面临被攻破的风险。这一天有个专属名称：Q-Day。要实现这一目标，绝不能指望数百万网站运营者各自钻研成为加密专家。它必须自动化。在此之前，启用抗量子连接需要手动配置：要么由 Cloudflare 主动开启，要么由源服务器强制要求。这很容易出错。但现在，一切都实现了自动……！ TLS 1.3 握手：猜键交换算法 每个安全 Web 连接的起点都是 TLS 握手，该过程用于验证服务器身份并派生共享密钥。我们之前关于 Automatic SSL/TLS 的博客文章详细解读了这一过程。 由于 Cloudflare 充当反向代理，看似单一的安全连接实际上是两条独立链路：一条在访客与 Cloudflare 之间，另一条在 Cloudflare 与源服务器之间。每条链路各自独立运作，拥有独立的握手、身份校验和加密密钥。 Automatic Key Exchange 作用于第二条连接。当 Cloudflare 连接源服务器时，Cloudflare 充当 TLS 客户端并发起握手。我们通过发送 ClientHello 消息来启动连接，其中包含主机名及支持的密钥协商算法列表。
理想情况下，TLS 1.3 只需一次网络往返就能建立新的加密连接（如上图左侧所示）。此时 Cloudflare 发送 ClientHello，其中列出支持的密钥协商算法，并附带一个或多个 client keyshare（客户端密钥共享）。如果源站接受这个选择，就会直接响应并完成握手。这种“预测式”密钥交换是 TLS 1.3 的创新点，也是它比 TLS 1.2 更快的主要原因。
如果源站更倾向于其他算法，则会返回一个 HelloRetryRequest（HRR），让 Cloudflare 重试（如上图右侧所示）。Cloudflare 随后会根据源站指定的密钥协商算法生成新的 client keyshare，并发送第二个 ClientHello。连接最终仍能建立，但这次重试额外增加了一个完整的网络往返，Cloudflare 才能开始获取内容。这就像在 Mario Kart 里错过了捷径：你照样能到终点，只是损失了本该省下的时间。
无论哪种情况，服务器都会用 client keyshare 生成共享密钥，并返回一个 server keyshare，客户端同样能据此计算出共享密钥。之后，双方就用这个共享密钥通过对称加密算法（如 AES）保护连接的其余部分。
稳妥猜测的代价
多年来，我们对源站 TLS 1.3 连接的初始 client keyshare 选择一直是固定的：总是发送 X25519，同时声明支持其他密钥协商算法。这是稳妥的策略，因为超过 95% 的源站都支持 X25519，而不支持的源站也可以通过 HelloRetryRequest（HRR）重试，不会中断连接。
然而，X25519 面临量子计算机的威胁。自 2023 年 9 月 起，我们已向源服务器提供后量子密钥协商支持：最初采用 X25519Kyber768Draft00，现改用 X25519MLKEM768（该算法的标准版本）。关键在于，广播支持并不等同于在 ClientHello 中直接携带密钥共享。X25519MLKEM768 的密钥共享占 1,216 字节，而 X25519 仅 32 字节，这会导致 ClientHello 超过单个网络数据包的大小。虽然 TLS 标准允许多包传输，但部分传统中间盒（middlebox）和源服务器在接收跨多个数据包传输的 ClientHello 时会出错。在我们此前的研究中，约 0.34% 的源服务器在首次接收后量子密钥共享时无法完成 TLS 握手，而绝大多数源服务器仍依赖经典的 X25519。
因此，为防止源连接可能出现的故障，我们将 HRR 用作安全阀。我们仅广播后量子支持，发送经典的 X25519 密钥共享，并要求具备后量子能力的源服务器通过重试机制请求后量子交换。对于不支持 HRR 流程的源服务器，客户可以选择手动配置，优先使用 X25519MLKEM768 密钥共享。从 2023 年至今，支持后量子密钥交换算法的源服务器比例从 0.5% 增长至 12.8%，随着托管栈升级至 PQ 安全算法，预计这一比例还将持续上升。
虽然这种默认配置是安全的，但它增加了不必要的延迟，原因有两点：
- 尽管OpenSSL、BoringSSL 和 rustls 的现代化版本均支持 X25519MLKEM768，但它们对经典 X25519 密钥共享的处理方式各不相同。部分旧版本构建可能默认接受该经典密钥，除非明确配置为优先使用抗量子安全密钥；而较新的构建则会立即发起 HRR，以优先建立抗量子连接。
- 超过 6% 的源站更倾向于使用 P-256 或 P-384 而非 X25519。由于我们在初始客户端密钥共享上采用了静态选择策略，这导致即使是纯经典连接也会触发一次 HRR 往返。
为消除这些无效的往返，我们在自动 SSL/TLS框架中，开始扫描源站服务器以映射其确切的密钥协商能力。利用这些扫描结果，我们可以针对每个源站自动定制初始密钥共享策略：在不增加站点故障风险的前提下最大化抗量子连接数量，同时提升适用域名的连接速度。
将自动 SSL/TLS 拓展至抗量子时代
自动 SSL/TLS 现在包含了自动密钥交换功能。面对数百万个源站，盲目猜测不同的密钥共享策略存在运营风险，因为我们事先无法得知单个源站的具体配置。因此，我们不再进行能力推测，而是直接进行测量，复用已支撑自动 SSL/TLS 的扫描流水线。
对于日益增长的源站数量而言，这意味着在连接建立的第一次尝试中即可达成抗量子密钥协商，无需额外往返，也无需任何手动配置。
其工作原理如下：
- 对每个支持 TLS 1.3 的源站，我们会发起几次轻量的 TLS 握手，每次只提供一种密钥交换组：X25519、P-256、P-384、P-521 或 X25519MLKEM768。通过这些探测，我们就能摸清源站支持的全部算法。而且由于主动扫描不在生产流量路径上进行，我们可以在真实流量依赖之前，先确认源站以及中间网络能否处理更强密钥交换的连接。
- 一个域名下往往有多个子域名，它们可能解析到能力各不相同的源站。我们会逐个评估子域名，并按实际流量占比加权。这样得出的域名级偏好反映的是 HTTP 流量大小，而不是让一个闲置子域名和你最繁忙的端点平起平坐。比如，如果几乎全部流量都落在 www 和 api 子域名上，那么整个域名的密钥交换偏好就主要由这两个端点决定。
- 确定源站支持的密钥交换组后，我们会按严格的优先级选出最强的候选算法：优先选择后量子混合算法（X25519MLKEM768），否则回退到源站接受的最快经典算法（X25519、P-256、P-384 或 P-521）。
- 一旦确定了源站的最优密钥交换算法，我们就会开始灰度发布。新的偏好先只应用到该源站的一小部分流量上，系统会持续监控失败率和 HelloRetryRequest（HRR）率。如果重试率超过该源站的基线，我们就回滚这次变更，原理和 Automatic SSL/TLS 回滚可能出问题的加密模式升级一样。最坏情况下，回滚只是多付出一个往返延迟，整个发布期间 TLS 连接也不会中断。
- 源站配置会随时间变化：客户迁移到新的负载均衡器、某个 TLS 库在例行更新中加入了后量子支持、运维人员关掉了对旧密钥交换算法的支持。我们每天都会重新扫描所有源站，因此新增后量子支持、或不再支持我们正在使用的曲线的服务器，都会在下一次扫描时获得新的偏好。
对大多数客户而言，无需进行任何配置。如果您的源站支持 TLS 1.3，我们将自动协商其支持的最强密钥交换算法。例如，若源站支持 X25519MLKEM768，Cloudflare 会优先选择它，从而无需额外往返延迟即可建立后量子密钥协商。
配置自动密钥交换
自动密钥交换默认对所有现有和新域名处于激活状态，大多数场景下无需手动操作。如有需要，您可以在 Cloudflare 控制台的“SSL/TLS > 概览 > 配置 > 源站连接与后量子加密”页面中独立管理这些设置。
启用自动密钥交换功能后，Cloudflare 会在带外（out-of-band）扫描您的源站，并优先使用动态选定的 keyshare（密钥共享）。若关闭该功能，扫描将停止，Cloudflare 会回退到固定的默认密钥协商顺序。
我们还在自动密钥交换下新增了一项合规性要求设置。您可以通过它筛选 Cloudflare 被允许使用和宣告支持的源站连接密钥协商算法。一旦配置完成，自动密钥交换及所有面向源站的流量将严格遵循这些规则：
- 后量子混合模式：将协商限制在混合后量子密钥协商算法（X25519MLKEM768）上，完全移除传统算法。此时，您所有成功的源站 TLS 1.3 连接都保证具备后量子安全性。
- 联邦信息处理标准（FIPS）：将协商限制在符合 FIPS 标准的密钥协商算法上。
同时勾选这两项，要求算法能同时满足两项标准；如果不存在共同支持的密钥协商算法，该配置将被拒绝。详情参见 Automatic Key Exchange 文档。
选择这些选项，本质上是配置你的意图，而非指定具体算法。这样即便合规标准演进或新的抗量子算法出现，配置也能自动保持最新。
不过，这些需求需谨慎对待。它们不会赋予源站新的密码学能力，只是限制了 Cloudflare 可协商的范围。
重要提示：如果在源站不支持 X25519MLKEM768 的情况下强制启用抗量子混合模式，双方将没有共同支持的算法，导致 所有 TLS 1.3 连接失败。 除非有严格的策略要求在所有连接中强制执行抗量子交换或 FIPS 合规，否则建议保持两项均未勾选，让 Automatic Key Exchange 安全地为你协商最优算法。
携手让互联网更安全、更快
Automatic Key Exchange 适用于源站支持 TLS 1.3 的域名（因为预测首选密钥协商算法是 TLS 1.3 专属特性）。该功能已默认开启，我们的扫描流水线已为超过一百万个域名 分配了密钥交换偏好，并在剩余网络中持续注册生效。
在最初这批域名中，我们发现大约64%仍保留经典 X25519 作为首选，因此连接行为没有任何变化。约33%的域名现在把首选设为 X25519MLKEM768，这样这些域名的流量在一个往返内就能获得针对“先窃取、后解密”（harvest-now, decrypt-later）量子攻击的防护。剩下的3%则选择了其源站偏好的其他经典曲线，如 P-384、P-256 或 P-521。
随着大规模推广的推进，这种延迟惩罚几乎已完全消失，适用于绝大多数具备后量子能力的源服务器：在当前扫描范围内，99.2% 的后量子 TLS 1.3 连接现在仅需一个往返即可握手完成。除了消除额外的往返外，我们观察到该范围内后量子源流量的连接数正从每天约 250 亿次增长至450 亿次。这一增长中有相当一部分源于 Automatic Key Exchange 将传统连接升级为扫描范围内源服务器的后量子偏好。
许多源服务器支持多种密钥协商算法，但并未指定首选算法。例如，支持后量子密钥协商的源服务器仍可能接受传统的（X25519）密钥份额，而不会拒绝它或发起 HRR。因此，被动观测无法揭示源服务器的完整能力。主动探测使 Automatic Key Exchange 能够发现数千个未在源流量中显示其后量子支持特性的源服务器。
一旦扫描器发现这些源服务器并更新其客户端密钥份额偏好，后量子连接迅速占据了流向这些源服务器流量的绝大部分。对于这些已升级的域名，其他传统密钥协商算法所占份额极小，主要源于包含后量子和仅传统后端的多源设置。
Automatic Key Exchange 的作用不仅限于推动后量子算法的采用。它还帮助源服务器匹配其首选的传统曲线（X25519 除外），从而降低了所有被扫描源服务器整体的 HRR 比率。
在启用自动密钥交换（Automatic Key Exchange）之前，扫描到的域名中，大约 52% 的源站连接需要 HRR（HelloRetryRequest）。启用后，这一比率骤降至 3.7%。避免 HRR 意味着省去了 TLS 连接建立过程中的一整个往返（round trip），使扫描到的源站 p90 延迟降低了 150 毫秒以上。这一优化尤其利好动态请求和 CDN 未命中的场景，因为这些请求可能需要与源站建立新的 TLS 1.3 连接，从而最终降低终端用户的感知延迟。通过现有 keep-alive 连接发送的请求无需重新握手，因此不受此影响。
服务器是否具备后量子能力？
你可以使用多种工具来检查服务器是否支持后量子（post-quantum）密钥协商。 我们通过 Cloudflare Radar 提供了其中一款工具。输入你的服务器域名或 IP 地址，我们就会检测其是否支持后量子 TLS 密钥交换。请注意，如果输入的是经由 Cloudflare 代理的域名，Radar 检测的是到 Cloudflare 的连接，而非其后端的源站服务器。
除了验证算法支持情况，我们还在该工具中增加了对后量子 TLS 实现缺陷的检测功能。如果检测结果为否定，工具还会尝试分析失败的具体原因。失败通常源于老旧的中间盒（middleboxes）、防火墙或服务器缓冲区丢弃多数据包负载，或无法重组跨 TCP 分段发送的 ClientHello。另一些情况下，源站遇到无法识别的密钥份额时，没有按 TLS 1.3 要求发送 HelloRetryRequest，而是直接放弃；或者虽然发送了 HelloRetryRequest，但无法完成后续的握手流程。
Radar 能让你清楚地看到网络路径是否能顺畅处理后量子流量。Automatic Key Exchange 不会对未通过这些检查的源站启用切换，因此通过检查才能让升级落地。
如果源站还不支持后量子密钥协商怎么办？
即使你的源站目前还不支持后量子加密，好消息是，启用 Auto Key Exchange 依然有好处。Automatic Key Exchange 会探测源站支持的算法。如果 X25519MLKEM768 不可用，Cloudflare 会继续使用兼容的经典密钥协商，并且仍能通过学习源站偏好的算法来避免不必要的 HelloRetryRequest 往返。不过，只有当源站本身已经支持该密钥协商算法时，Automatic Key Exchange 才会优先选择后量子连接。目前，我们网络中已有超过 12% 的独立源站支持后量子加密。随着最近版本的 BoringSSL、OpenSSL 和 rustls 相继加入支持，各 TLS 服务器实现对后量子安全算法的支持正在不断扩大。企业级源站技术栈、云负载均衡器和嵌入式 TLS 终结点也在按各自的节奏升级。
如果你想为域名的源站连接增加后量子保护能力，有两种选择：
- 使用 Cloudflare Tunnel。cloudflared 与 Cloudflare 之间的连接已经使用后量子密钥协商。当你无法修改公开源站端点的 TLS 软件时，这是最简单的方案。
- 你可以升级 TLS 端点。许多现有的框架和 TLS 库默认启用 X25519MLKEM768。不过，如果你此前手动配置了服务器的 TLS 允许曲线，这些旧设置可能会覆盖新的默认值。请务必审计所有终止或检查 TLS 的设备——包括负载均衡器、WAF 硬件以及其它中介盒子（middleboxes）——确保源站到 Cloudflare 之间的所有环节都启用了 X25519MLKEM768。如果你使用的是托管服务，请咨询供应商是否支持 X25519MLKEM768（多数供应商已支持）。
关于受支持的软件、配置示例及验证步骤，请参阅 Cloudflare 与源站之间的后量子密码学。
下一步计划
自 2024 年起，我们一直在公开构建 Automatic SSL/TLS 功能。Automatic Key Exchange 只是这一长期演进的第二步，并非终点。我们自那以后公开了路线图，并将在功能发布时持续更新进展。以下是我们正在开发的几项具体功能：
按源站细化偏好粒度
目前，Automatic SSL/TLS 在域名层级做出决策。单个源站服务器的行为可能会拖累整个域名的表现。我们正在开发按子域名/按源站的细粒度控制，以便密钥协商（以及 SSL/TLS 加密模式）可以根据服务于同一域名的多个源站进行差异化配置。
按需扫描
如果你的源站 TLS 栈刚完成升级，你不需要再等待 Automatic SSL/TLS 的下一次定期扫描。我们最初的思路是在跟上源站变更的同时，避免对返回相同安全信息的源站造成过多扫描负担。目前正在开发一个可选项，允许从仪表盘或 API 手动触发即时重扫描，这样源站升级后，你可以立即启用更优的密钥交换协议，而不必等待系统自动发现变更。
除了即时刷新功能，这个按需扫描还将直接集成在 Cloudflare 仪表盘，作为诊断工具使用。它支持你按需测试自己的源站服务器行为，精确查看其能成功协商哪些密钥交换协议，并分析失败原因（类似外部 Cloudflare Radar 扫描工具的功能）。
自动后量子源站认证
后量子密钥交换可防止未来的量子计算机解密当下的流量。但它无法防御攻击者利用量子计算机伪造证书来冒充你的源站。要弥补这一漏洞，需要后量子认证技术，今年早些时候，Authenticated Origin Pulls 和 Custom Origin Trust Store 开始支持ML-DSA 证书，正式引入了该功能。
这里有一个关键问题需要处理：协议降级。假设你的源站同时支持传统的RSA/ECDSA 证书和新的后量子 ML-DSA 证书，以便兼容旧客户端。在 Q-Day（量子威胁实际到来之日），夹在 Cloudflare 和你源站之间的主动攻击者可以拦截 TLS 握手，并悄无声息地丢弃后量子提议。Cloudflare 若只看到传统响应，就会回退到验证旧版 RSA/ECDSA 证书，而攻击者可以利用量子计算机伪造这种证书。
要在更广泛的 WebPKI 中防止这种降级攻击并不简单。有一种提议是让证书颁发机构（CA）在传统证书上附加一个后量子签名，以证明某台旧服务器确实还不支持 PQ。这对公共 Web 来说可能是个方向，但需要时间和多方协调。更快的方式（如果可行的话！）是彻底不再信任传统证书。
而对于源站连接，我们完全可以做到。我们计划扩展 Automatic SSL/TLS 扫描功能，检测源站是否支持后量子认证（ML-DSA 证书，未来还包括 Merkle Tree Certificates）。一旦扫描器识别出这样的源站，Cloudflare 就可以为需要严格后量子防护的客户自动禁用传统算法回退，在不影响未升级端点的前提下消除降级风险。
欢迎体验
在 Cloudflare，我们相信强大的互联网安全能力应该是免费、自动、默认开启的。Universal SSL 让浏览器到 Cloudflare 的连接实现了默认加密，Automatic SSL/TLS 则对 Cloudflare 到源站的连接做着同样的事情，如今更进一步覆盖到后量子密钥协商。
想了解你的源站当前的加密水平，可以查看控制台的 SSL/TLS 部分。想直接验证源站的后量子就绪情况，Cloudflare Radar 会告诉你是否需要升级服务器。如果你的源站已经支持后量子，Automatic Key Exchange 会告知 Cloudflare，让我们能更快、更安全地连接你的源站。