Cloudflare AKE 将原始 HelloRetryRequests 从 52% 削减至 3.7%

每次 Cloudflare 打开与源服务器的新 TLS 1.3 连接时，我们都必须做出猜测：该协议要求我们在发送的第一个数据包中承诺密钥协商算法，然后源服务器才告诉我们有关其自身或它可以支持的内容。如果我们猜对了，握手将在一次往返中完成。猜错了，源端回复了 HelloRetryRequest ，我们重新开始，连接需要两次往返。多年来，我们对互联网上每个来源的猜测都是相同的：X25519。得到了广泛支持，但事实证明，对于我们此后测量的大约 30% 的原始连接来说，它并不是最理想的。今天，我们宣布推出自动密钥交换，它是自动 SSL/TLS 的扩展，可以用测量代替猜测。我们探测每个起源，了解它支持和喜欢哪些密钥协商算法，然后在第一次尝试时使用该算法，在起源可以说话的地方首选后量子混合 X25519MLKEM768。随着跨源连接不断推出自动密钥交换，HelloRetryRequests 从大约 52% 下降到 3.7%，将 p90 的连接握手延迟缩短了 150 毫秒以上。此外，作为我们正在进行的部署的一部分，数十万个域现在拥有无需任何人配置的后量子起源连接，并且这个数字每天都在增长。虽然毫秒很重要，但第二部分可能更重要。现在的某个地方，对手正在记录它还无法读取的加密流量，并押注它将来能够读取（这种攻击称为“立即收获，稍后解密”）。 Cloudflare 正全力争取到 2029 年使互联网实现量子安全，一些行业专家估计经典加密算法可能会在这一年被攻破。那一天有一个名字：Q-Day。满足这一期限不能依赖于数以百万计的网站运营商都成为专家密码学家。它必须是自动的。直到今天，首选后量子连接需要手动设置：要么从 Cloudflare 端打开它们，要么让源服务器坚持使用它们。很容易出错。但今天它只是……自动的！ TLS 1.3 握手：猜测密钥交换算法 每个安全 Web 连接都以 TLS 握手开始，该握手对服务器进行身份验证并派生共享密钥。我们之前的自动 SSL/TLS 博客文章详细介绍了该过程。由于 Cloudflare 作为反向代理运行，看似单一的安全连接实际上有两个：一个在访问者和 Cloudflare 之间，另一个在 Cloudflare 和源服务器之间。每个连接独立运行，具有自己的握手、身份检查和加密密钥。自动密钥交换会影响第二个连接。当 Cloudflare 连接到源时，Cloudflare 充当 TLS 客户端并且必须开始握手。我们通过发送包含主机名和支持的密钥协商算法列表的 ClientHello 消息来启动连接。在幸福的道路上，TLS 1.3 可以在一次网络往返中建立一个新的加密连接（如上图左侧所示）。在这种情况下，Cloudflare 会发送一个 ClientHello，列出其支持的密钥协商算法以及一个或多个客户端密钥共享。如果源端接受该选择，它将做出响应并完成握手。这种预测性密钥交换是 TLS 1.3 的一项创新，也是它比 TLS 1.2 更快的重要原因。否则，如果源端更喜欢不同的选项，它会发送 HelloRetryRequest (HRR) 并要求 Cloudflare 重试（上图中右侧的流程）。然后，Cloudflare 发送第二个 ClientHello，根据源指定的密钥协商算法生成新的客户端密钥共享。连接仍然成功，但重试会在 Cloudflare 获取内容之前添加完整的网络往返。这就像《马里奥赛车》中错过了捷径：你仍然到达终点线，但你失去了捷径本应节省的时间。无论哪种方式，服务器都会使用客户端 keyshare 生成共享密钥。然后，服务器返回一个服务器密钥共享，客户端也可以用它来计算共享密钥。此共享密钥用于使用对称加密（例如 AES）保护连接的其余部分。安全猜测的成本多年来，我们对使用 TLS 1.3 的原始连接的最初客户端密钥共享猜测是静态的；我们总是发送 X25519，同时宣传对其他密钥协议算法的支持。这是一个安全的策略，因为超过 95% 的源支持 X25519，任何不支持的源都可以在不中断连接的情况下发出 HelloRetryRequest (HRR)。然而，X25519 很容易受到量子计算机的攻击。自 2023 年 9 月以来，我们一直在宣传支持后量子密钥协议的起源：首先是 X25519Kyber768Draft00，今天是 X25519MLKEM768（算法的标准化版本）。至关重要的是，广告支持不同于通过密钥共享进行领导