自动密钥协商：为每天 450 亿次连接实现更快、抗量子的 TLS 握手

每次Cloudflare开启新的TLS 1.3连接到源服务器时，我们都必须猜测：协议要求我们在发送的第一个数据包中承诺密钥协议算法，而源方还未告诉我们任何关于自身或支持什么的信息。

如果我们猜对了，握手会在一次往返中完成。猜错了，源方会回复HelloRetry请求，我们重新开始，连接费用为两次往返。

多年来，我们对互联网上每个起源的猜测都是一样的：X25519.虽然被广泛支持，但事实证明，大约有30%的不理想表现我们后来测量的起源联系。

今天我们宣布自动密钥交换，是 的扩展自动SSL/TLS这会用测量替代猜测。我们探测每个原点，了解它支持和偏好的密钥一致算法，然后在第一次尝试时先用该算法，优先选后量子混合体 X25519MLKEM768只要起源能说出它。

随着自动密钥交换在源地连接间的持续推广，HelloRetryRequests 的使用率从约 52% 降至 3.7%，连接握手延迟在 p90 时减少了超过 150 毫秒。

此外，作为我们持续推广的一部分，数十万域名现在拥有无需配置的后量子起源连接，且数量每天都在增长。

虽然毫秒很重要，但第二部分可能更为重要。此刻某处，攻击者正在记录它尚未读取的加密流量，赌未来它能读取（一种被称为先收获，解密后).Cloudflare正全力以赴打造互联网2029年实现量子安全，这一年，一些业内专家估计经典加密算法可能会被破解。

这一天有个名字：Q日。能否完成这个截止日期，不能指望数百万网站运营者各自成为密码学专家。必须是自动的。直到今天，偏好后量子连接需要手动设置：以下你从Cloudflare那边开启它们或者你让原始服务器坚持要他们。

很容易搞错。但今天它只是......自动的！

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

每个安全的网络连接都以TLS握手开始，TLS握手对服务器进行认证并生成共享密钥。我们之前关于自动SSL/TLS的博客文章详细介绍这个过程。

由于 Cloudflare 作为反向代理，看似单一安全连接实际上是两个连接：一个是访问者与 Cloudflare 之间的连接，另一个是 Cloudflare 与源服务器之间的连接。

每个连接独立运作，拥有自己的握手、身份检查和加密密钥。

自动密钥交换影响第二个连接。当Cloudflare连接到起始节点时，Cloudflare作为TLS客户端，必须开始握手。我们发起连接通过发送 ClientHello 消息包含主机名和支持的密钥协同算法列表。

在良好路径下，TLS 1.3 只需一次网络往返即可建立新的加密连接（如上图左侧所示）。此时，Cloudflare 发送一个 ClientHello，列出其支持的密钥协议算法，并附上一个或多个客户端密钥共享.如果起源接受该选择，它会响应，握手完成。

这种预测密钥交换是 TLS 1.3 的创新，也是它比 TLS 1.2 更快的重要原因。

否则，如果原方偏好其他选项，则发送HelloRetry请求（HRR）并请求Cloudflare再次尝试（上图右侧的流程）。Cloudflare随后发送第二个ClientHello，生成一个新的客户端密钥共享基于源节点指定的密钥协议算法。

连接仍然成功，但重试会在Cloudflare获取内容前额外绕行整个网络。这就像错过了马里奥赛车中的捷径：你仍然到达终点线，但失去了快捷方式本应节省的时间。

无论如何，使用客户端密钥共享服务器生成共享密钥。服务器随后返回服务器密钥共享客户端还可以通过该密钥计算共享密钥。该共享密钥用于保护连接的其余部分，使用对称密码学，例如：AES.

安全猜测的代价

多年来，我们最初用TLS 1.3对起始连接的客户端密钥共享猜测是静态的;我们总是发送X25519同时广告支持其他密钥协议算法。这是一个安全的策略，因为超过95%的起源支持X25519，任何不支持的源端都可以在不中断连接的情况下发出HelloRetryRequest（HRR）。

然而，X25519 容易受到量子计算机的影响。自2023年9月我们曾宣传支持后量子密钥与起源协议：最初名为X25519Kyber768Draft00，如今则称为X25519MLKEM768（算法的标准化版本）。

关键是广告支持与ClientHello中用密钥共享引向不同。X25519MLKEM768密钥共享为1,216字节，而X25519为32字节，使ClientHello超过单个网络数据包。

虽然TLS标准允许多数据包段，但一些遗留的中介箱和源服务器可能会失败当接收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的扫描流水线。

对于越来越多的起点，这种方式在首次尝试连接建立时就能实现后量子密钥协议，无需额外的往返，也无需手动设置。

工作原理如下：

1. 对于每个支持 TLS 1.3 的起点，我们运行一系列轻量级 TLS 握手，每个握手仅提供一个密钥协议组：X25519、P-256、P-384、P-521 或 X25519MLKEM768。这些探针共同告诉我们源支持的完整算法集。由于主动扫描发生在生产流量路径之外，我们确认你的起点和中间网络都能处理更强密钥协议的连接，而实际流量则依赖于它。
2. 一个域通常会先行管理多个子域，这些子域可能解析到不同的来源，能力各异。我们会独立评估每个子域，并根据其实际流量量加权结果。这确保了域范围的偏好反映HTTP流量，而不是将休眠子域与你最忙碌的终端权重相等。例如，如果几乎所有流量都到达你的www和api子域名，这些终端将极大地决定整个域的密钥交换偏好。
3. 从原点支持的密钥一致群中，我们通过严格的优先顺序选择最强的候选群：先选后量子混合体（X25519MLKEM768），然后退回到原点接受的最快经典算法（X25519、P-256、P-384或P-521）。
4. 一旦我们知道某个源头偏好的最佳密钥协议，我们就开始推送。新的优先级优先权首先分配到该源地的一小部分流量，系统在运行过程中监控其失败率和HelloRetryRequest（HRR）速率。如果重试超过该源区的基线，我们会以同样方式回滚该更改自动SSL/TLS会撤销可能出现异常行为的加密模式升级。在最坏的情况中，错误的密钥协议偏好会让我们损失额外的往返延迟，而不是在部署阶段内TLS连接中断。
5. 起源配置会随时间变化：客户更换到新的负载均衡器，TLS库在常规版本中发布后量子支持，操作员关闭旧的密钥协议算法支持。我们每天都会重新扫描每个原点，因此添加后量子支持或停止支持我们之前使用的曲线的服务器，在下一次扫描时会获得新的优先级。

对大多数客户来说，无需配置。如果您的源节点支持TLS 1.3，我们会自动协商其支持的最强密钥交换，例如，如果某个节点支持X25519MLKEM768，Cloudflare更倾向于采用该密钥，并可在无额外往返延迟的情况下建立量子后密钥协议。

配置自动密钥交换

自动密钥交换默认对所有现有和新域名开放，大多数设置无需手动操作。如果你愿意，可以在Cloudflare仪表盘的SSL/TLS下独立管理这些设置>概览>配置>起源连接与后量子加密.

启用自动密钥交换开关后，Cloudflare 会以动态选择的密钥共享扫描你的源地址，并引导你。禁用密钥共享后，扫描停止，Cloudflare 会恢复为固定/静态默认密钥协议顺序。

我们还推出了新的合规要求制定在自动密钥交换下。您可以筛选 Cloudflare 允许使用的密钥协议，并宣传对源连接的支持。配置后，自动密钥交换及所有面向源的流量严格遵守以下规则：

• 后量子混合：仅限于混合后量子密钥协议（X25519MLKEM768），完全移除经典算法。你所有成功的起源TLS 1.3连接都将是保证为了实现后量子安全。
• 联邦信息处理标准（FIPS）：仅限于谈判符合FIPS标准的关键协议。

选择这两个选项需要一个同时满足这两个条件的算法;如果不存在重叠的密钥一致，则该配置被拒绝。参见自动密钥交换文档细节。

选择这些选项，你是在配置意图，而非特定算法。这确保了随着合规标准的演变或新的后量子算法出现，你的配置自动保持最新。

不过，这些要求值得谨慎对待。它们并不赋予原始人新的加密能力，只是缩小了Cloudflare可协商的范围。

重要说明：在缺乏X25519MLKEM768支持的原点上强制执行后量子混合，会不产生互支持的算法，导致全部TLS 1.3 连接会失败。除非你有严格的政策义务在每个连接中强制执行后量子交换或FIPS合规，否则请保持两个选项不选，让自动密钥交换安全地协商最优算法。

共同让互联网更安全、更快捷

自动密钥交换适用于源地使用 TLS 1.3 的域名（因为预测首选密钥协议方法是一种仅支持TLS 1.3的功能).默认启用了，我们的扫描流水线已经为 分配了密钥交换偏好超过一百万个域名而剩余网络的招生仍在继续。

从最初的那一批人中，我们大致发现了64%他们偏好使用经典的X25519，因此连接方式没有变化。周边33%其中之一现在将优先设置为X25519MLKEM768，这使得流量流向那些受保护的源地先收获，解密后量子攻击一次，完成一次往返。

剩余的3%选择根据其原点偏好的不同经典曲线，如P-384、P-256或P-521。

每天约有9,000个域的密钥协同偏好设置为X25519以外的密钥协商方法。几乎所有这些域都直接转向后量子密钥交换，其余域则采用由其源TLS配置更好地支持的其他经典曲线。

如前所述，在自动密钥交换出现之前，几乎每次量子起源后的握手都需要HelloRetryRequest（HRR），因为我们的静态初始猜测默认为经典的X25519。

结果是后量子连接在完成TLS握手前必须支付第二次往返。

随着推广的进行，几乎所有平台的延迟惩罚几乎消失了后量子能力起源：目前扫描的起源队列中，99.2%的后量子TLS 1.3连接在一次往返中完成.除了取消额外的往返外，我们看到在该群体中，后量子起源的流量从大约250亿连接持续增长到每天450亿。

这一增长的重要部分来自自动密钥交换将经典连接升级为后量子对扫描源的偏好。

许多起源支持多个密钥协议算法，但不会偏爱其中一个。例如，支持后量子密钥协议的源区仍可接受经典（X25519）密钥共享，而不会拒绝或发出HRR。

因此，被动观察无法揭示起源的全部能力。主动探测使自动密钥交换能够发现数千个源点在其起源流量中未曾出现过后量子支持。

一旦扫描器发现了这些起源，并更新了客户端密钥共享偏好，后量子连接迅速占据了这些源头的绝大多数流量。其他经典密钥协商算法在这些升级域中所占比例远小得多，主要由多源配置和后量子和纯经典后端混合驱动。
自动密钥交换不仅推动后量子时代的采用。它还帮助将原点与其偏好的经典曲线（除X25519外）配对，从而降低所有扫描原点的整体HRR率。

在启用自动密钥交换之前，扫描域名的起始连接大约有52%需要HRR。这一比例降至仅3.7%。避免HRR会从TLS连接设置中完成整个往返。扫描源的P90延迟减少了150毫秒以上。

这尤其有利于动态请求和CDN缓存未命中，这些可能需要对源节点进行新的TLS 1.3连接，从而降低眼睛的延迟。通过现有保持生命连接发送的请求不需要新的握手，因此不受影响。

服务器具备后量子能力吗？

有许多不同的工具可以用来判断服务器是否支持后量子密钥协议。我们通过Cloudflare Radar提供其中一种工具.输入服务器的主机名或IP地址，我们会检查它是否支持后量子TLS密钥交换。

注意，如果你输入由Cloudflare代理的主机名，Radar会检查连接到Cloudflare的连接，而不是你背后的原始服务器。

除了验证算法支持外，我们还增加了工具中检查量子后TLS实现的错误.如果结果为阴性，它还会尝试描述失败的原因。失败通常源于遗留的中介箱、防火墙或服务器缓冲区丢弃多包负载，或未能重组跨TCP段的ClientHello。

有时，源方放弃未识别的密钥共享，而非发送TLS 1.3要求的HelloRetryRequest，或者发送密钥后无法完成握手。

雷达能清晰显示网络路径是否能干净处理后量子流量。自动密钥交换不会切换源头未通过这些检查的域，因此清除这些检查才是升级的关键。

如果你的起源还不支持后量子密钥协议怎么办？

即使你的起源地区目前还不支持后量子加密，好消息是启用自动密钥交换依然会带来好处。自动密钥交换找到你的Origin支持什么。如果X25519MLKEM768不可用，Cloudflare继续使用兼容的经典密钥协议，并且通过了解你的Origin更喜欢哪种密钥，仍然可以避免不必要的HelloRetryRequest往返。

然而，自动密钥交换只能优先考虑后量子连接，前提是你的源服务器已经支持密钥协议算法。今天，我们看到12%的个人起源我们的网络支持后量子加密。

后量子安全算法TLS服务器实现中的支持随着 的最新版本 正在增加BoringSSL,OpenSSL， 和沙沙声包括支持。企业起源堆栈、云负载均衡器和嵌入式TLS终端都在按自己的时间表升级。

如果你想为域的源端连接增加后量子保护能力，你有两个选择：

• 你可以用Cloudflare Tunnel。Cloudflare与Cloudflare之间的联系已经使用后量子密钥协议。当你无法更改公网端点的TLS软件时，这是最简单的选择。

• 你可以升级你的TLS端点。许多现有框架和TLS库默认启用X25519MLKEM768。但如果你之前手动为服务器的TLS配置配置设置了允许曲线，这些遗留设置可能会覆盖新的默认设置。重要的是要审计所有终止或检查TLS的设备——包括负载均衡器、WAF设备和其他中间箱——以确保X25519MLKEM768在你的源节点和Cloudflare之间的所有设备都被启用。如果你使用托管托管服务，问问你的提供商是否支持X25519MLKEM768（很多都支持）。

参见Cloudflare与你们起源之间的后量子密码学支持的软件、配置示例和验证步骤。

接下来是什么

我们一直在构建自动SSL/TLS自2024年以来公开发表.自动密钥交换是一个更长弧线中的第二步，而非最后一步。自那以后我们一直公开了路线图内容，并将在发布时持续提供更新。

我们正在进行的一些具体工作：

按原产地偏好的粒度

如今，自动SSL/TLS在域层级做出决策。一个源服务器的行为可能会拖累整个域的发展。我们正在研究每个子域/每个源的粒度，以确保密钥一致性（和SSL/TLS加密模式）可以在服务同一域的多个源区之间有所不同。

按需扫描

如果你刚刚升级了Origin的TLS协议栈，就不必等待下一次自动SSL/TLS的定时扫描。最初，我们希望扫描足够多以跟上源节点的变化，但又不想给最终返回相同安全信息的Origins带来负担。

我们正在开发一个选项，可以从仪表盘或API触发按需重扫，这样在Origin升级后，你可以立即切换到更好的密钥协议，而不必等待我们的系统赶上进度。

除了触发即时更新外，这种按需扫描将直接存储在你的Cloudflare仪表盘中，作为诊断工具。它会让你按需测试自己原始服务器的行为，准确判断它能成功协商哪些关键协议，并描述任何失败的原因（类似于外部Cloudflare雷达扫描工具）.

自动后量子起源认证

后量子密钥协议防止了当前的流量被未来的量子计算机解密。对于利用密钥伪造证书冒充你来源的攻击者，这无济于事。弥合这一差距需要后量子认证，而今年早些时候加入了Origin Connections。

当认证起源拉取和自定义起源信任存储获得支持ML-DSA证书.

这里有一个重要的问题需要处理：降级.想象一下你的Origin服务器同时支持经典服务器RSA/ECDSA证书以及新的后量子ML-DSA证书，防止遗留客户端崩溃。

在Q日，处于Cloudflare和你源区之间的活跃对手可以截获TLS握手，悄无声息地放弃后量子协议。Cloudflare只看到经典反应，会退回验证遗留RSA/ECDSA证书，攻击者可以通过量子计算机伪造该证书。

防止在更广泛的WebPKI中出现这种降级很复杂。一种建议的路径是证书授权中心（CA）在经典证书上进行后量子签名，以证明遗留服务器确实还不支持PQ。

虽然这对公共网络来说是可能的方向，但需要时间和协调。最快（如果可能的话！）是完全别再相信古典证书了。

对于起源连接，我们做到了！我们计划扩展自动SSL/TLS扫描，以检测后量子认证（ML-DSA证书）中的起源支持（ML-DSA证书;以及未来默克尔树证书).一旦我们的扫描仪识别出此类起源，Cloudflare就能自动禁用经典备份，满足要求严格后量子保护的客户，消除降级风险，同时不中断未升级的终端。

看看吧

在Cloudflare，我们相信强大的互联网安全应该是免费的、自动化的，并且默认开启。通用SSL使默认加密成为浏览器与Cloudflare连接的真实功能。

自动SSL/TLS也在为Cloudflare到源的连接做同样的事，现在将这项工作扩展到后量子密钥协议。

如果你想看看你现在的起源加密级别，可以查看SSL/TLS部分你的仪表盘。如果你想直接验证你起源的后量子准备状态，Cloudflare 雷达它会告诉你需要更新服务器堆栈。

如果你的源节点已经支持后量子，自动密钥交换会通知Cloudflare，这样我们就能更快更安全地连接到你的源节点。