背景：TLS 1.3 源站握手中的“猜测”问题

Cloudflare 作为反向代理，与访客及源站分别建立独立 TLS 连接。在与源站握手时，Cloudflare 作为客户端必须在首个 ClientHello 中提交密钥协商算法与密钥分享（keyshare）。若源站不支持所选算法，会返回 HelloRetryRequest（HRR），导致额外一个网络往返。

过去 Cloudflare 对所有源站统一默认发送 X25519 的 keyshare。虽然兼容性好，但实测约 30% 的源站连接因此并非最优：部分源站偏好 P-256/P-384，或支持后量子算法却因默认未带头而需重试。

Automatic Key Exchange 的作法

Cloudflare 将原有 Automatic SSL/TLS 的扫描机制扩展，主动对每台支持 TLS 1.3 的源站发起几次轻量握手探测，分别尝试 X25519、P-256、P-384、P-521 与 X25519MLKEM768，明确其支持与偏好。

  • 依据探测结果，在首次 ClientHello 中直接携带对应源站偏好的 keyshare；
  • 若源站支持，优先使用标准化后量子混合算法 X25519MLKEM768；
  • 无需站长手动配置，避免因大体积 PQ keyshare 触发老旧中间设备兼容问题。

实测收益

在逐步全量上线后：

  1. HRR 比例由约 52% 降至 3.7%；
  2. p90 握手延迟降低超过 150ms；
  3. 数十万域名已自动获得后量子源站连接，且每日增长。

此前由于 PQ keyshare 体积达 1216 字节（X25519 仅 32 字节），直接发送可能使 ClientHello 跨包而被部分旧设备丢弃；因此 Cloudflare 曾仅通告支持、靠 HRR 升级。现通过先探测后连接，兼顾了安全与可用。

行业估算 2029 年（Q-Day）经典加密或被量子计算破解，先行记录流量待日后解密的“ harvesting now, decrypt later”攻击已成现实威胁。

对读者的意义 / 技术解读

对运维与 SRE 而言，该方案展示了一种可借鉴的“测量驱动协商”思路：在无法预知对端密码学栈时，用带外探测代替盲目猜测，既能压降 TCP/TLS 建连延迟，又能平滑推进后量子迁移。对于使用 CDN 或反向代理的站点，应关注源站 TLS 栈是否支持 X25519MLKEM768，并确认边缘侧是否已开启类似自动优化，以减少跨境或跨省链路下的首包时间（TTFB）。此外，HRR 引发的额外 RTT 在长肥网络中代价显著，监控握手阶段指标应纳入可用性观测体系。