Cloudflare 与源服务器之间的后量子

本页涵盖 Cloudflare 边缘与源服务器之间 TLS 连接上的后量子密码学。Cloudflare 在此连接上同时支持后量子密钥协商（X25519MLKEM768）和后量子签名（通过 Authenticated Origin Pulls 和 Custom Origin Trust Store 的 ML-DSA）。

如果您希望在不管理公开暴露的 TLS 端点证书的情况下将源连接到 Cloudflare，Cloudflare Tunnel 是后量子源连接的另一种选择。Cloudflare Tunnel 在 cloudflared 与 Cloudflare 网络之间的 TLS 连接上使用后量子密钥协商。该路径上的身份验证尚未使用后量子签名。

如关于 PQC 中所述，Cloudflare 已部署混合密钥协商支持，其中包括 TLS 1.3 中最常见的密钥协商 X25519 和后量子安全的 ML-KEM。

使用 X25519 时，ClientHello ↗ 几乎总是适合单个网络数据包。然而，添加 ML-KEM 后，ClientHello 通常会被拆分为两个数据包。

这提出了源服务器——以及其他中间设备（路由器、负载均衡器等）——将如何处理此行为变化的问题。尽管 TLS 1.3 标准（RFC 8446 ↗）允许拆分 ClientHello，但由于协议僵化 ↗和实现缺陷，拆分的 ClientHello 可能无法得到良好处理。详情请参阅我们的博客文章 ↗。

为降低连接到尚未准备好混合密钥协商的服务器时出现问题的风险，Cloudflare 利用 HelloRetryRequest。这意味着，Cloudflare 默认不会立即发送 X25519MLKEM768 作为 keyshare ¹，而只会通告对其的支持。

如果源支持后量子混合密钥协商，它可以使用 HelloRetryRequest 向 Cloudflare 请求。

上述方法是 Cloudflare 用于支持所有出站连接的后量子方法。但是，如果您的源服务器支持 PQC 并偏好使用它，您可以使用 API 调整 Cloudflare zone 设置并避免额外的往返。

也可以使用同一 API 端点选择退出 PQC。

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/cache/origin_post_quantum_encryption" \
	--request PUT \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"value": "<YOUR_CHOSEN_SETTING>"
	}'

可能的值为：

• supported（兼容性最佳）：通告支持后量子密钥协商，但在第一个 ClientHello 中发送经典 keyshare。
• preferred（性能最佳）：在第一个 ClientHello 中发送后量子 keyshare。Cloudflare 继续通告对经典 keyshare 的支持。
• off：不向源发送或通告后量子密钥协商支持。

要确保源服务器偏好后量子密钥协商，请使用 BoringSSL ↗ 的 bssl 工具：

$ bssl client -connect (your server):443 -curves X25519MLKEM768

自 2026 年中期起，Cloudflare 在两个面向源的功能中支持 ML-DSA ↗ 后量子签名：

• Authenticated Origin Pulls (AOP) — Cloudflare 在到源的 mTLS 握手期间呈现 ML-DSA 客户端证书。
• Custom Origin Trust Store (COTS) — Cloudflare 在 Full (strict) 加密模式 下验证源服务器证书时信任 ML-DSA 证书颁发机构。

两者可以独立使用或一起使用。一起使用时，除了后量子密钥协商之外，还可以在 Cloudflare 边缘与源服务器之间建立端到端后量子身份验证。

• 源上的 TLS 库支持 ML-DSA — 例如 OpenSSL ↗ 3.5.0 或更高版本。更多选项请参阅 PQC 支持。
• 工作站上安装 OpenSSL ↗ 3.5.0 或更高版本以生成证书。
• 协商 TLS 1.3 的源服务器。ML-DSA 签名在 TLS 1.2 及更早版本中不可用。

以下命令使用 ML-DSA-44 创建私有证书颁发机构和链到它的叶证书。为 AOP 客户端证书重复一次，如果您也管理 COTS 服务器端，则为 COTS 重复一次。

# Private ML-DSA-44 CA (30-year validity)
openssl genpkey \
  -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out ca.key
openssl req -new -x509 \
  -key ca.key \
  -out ca.crt \
  -days 10950 \
  -subj "/CN=ML-DSA Origin CA"

# Leaf certificate signed by the CA (15-year validity)
openssl genpkey \
  -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out leaf.key
openssl req -new \
  -key leaf.key \
  -out leaf.csr \
  -subj "/CN=origin.example.com"
openssl x509 -req \
  -in leaf.csr \
  -CA ca.crt -CAkey ca.key \
  -CAcreateserial \
  -out leaf.crt \
  -days 5475 \
  -extfile <(printf "basicConstraints=CA:FALSE\nkeyUsage=digitalSignature\nsubjectAltName=DNS:origin.example.com\n")

-provparam ml-dsa.output_formats=seed-only 标志是必需的，以便私钥以 FIPS 204 种子形式写入，而不是作为扩展私钥。这是 Cloudflare 目前在上传时唯一接受的格式。

验证生成的证书：

openssl x509 -in leaf.crt -noout -subject -issuer -dates -ext subjectAltName

ML-DSA 客户端证书同时支持zone 级和按主机名 AOP。按照生成 ML-DSA 证书颁发机构和叶证书中的说明生成 ML-DSA CA 和叶证书，然后按照您正在配置的范围的设置指南操作。全局 AOP 范围使用 Cloudflare 提供的证书且不可配置。

在源服务器端，安装 ML-DSA CA 证书（之前生成的 ca.crt 文件），以便 TLS 服务器可以验证 Cloudflare 呈现的客户端证书。对于 nginx，如下所示：

ssl_client_certificate /etc/ssl/cloudflare-aop-ca.crt;
ssl_verify_client      on;

完整的源端配置请参阅 AOP 源服务器设置指南。

将 ML-DSA CA 证书（之前生成的 ca.crt 文件）上传为 Custom Origin Trust Store 条目。Cloudflare 将在 Full (strict) 加密模式 下信任链到该 CA 的任何源服务器证书。

在源服务器端，将 ML-DSA 叶证书及其私钥作为 TLS 服务器证书呈现：

ssl_certificate     /etc/ssl/origin-mldsa.pem;
ssl_certificate_key /etc/ssl/origin-mldsa.key;
ssl_protocols       TLSv1.3;

配置 AOP 和 COTS 后，您可以从具有 ML-DSA 支持的主机验证后量子源握手。例如，在使用 OpenSSL 3.5.0 或更高版本的机器上，直接连接到源并确认握手使用 ML-DSA：

openssl s_client \
  -connect origin.example.com:443 \
  -servername origin.example.com \
  -CAfile ca.crt \
  -cert leaf.crt \
  -key leaf.key \
  -brief

输出应显示 Signature type: mldsa44 和 Negotiated TLS1.3 group: X25519MLKEM768。

在身份验证侧呈现 ML-DSA 证书本身并不足够。要真正获得后量子身份验证，_验证_侧必须拒绝经典（非后量子）证书。如果验证方仍接受经典证书，攻陷该经典密钥的攻击者可以通过路径攻击 ↗冒充对等方 — 一种使后量子保护失效的降级。

• Custom Origin Trust Store (COTS)： 仅上传 ML-DSA 证书颁发机构。如果您在信任存储中保留经典 CA 与 ML-DSA CA 并存，Cloudflare 仍将接受链到经典 CA 的源证书，使连接容易受到降级攻击。上传 COTS CA 已经替换了 zone 的默认公开受信任 CA（请参阅上面的 caution），因此请确保您上传的每个 CA 都是后量子的。
• Authenticated Origin Pulls (AOP)： 配置源服务器要求 ML-DSA 客户端证书并拒绝经典客户端证书。Cloudflare 呈现 ML-DSA 证书只有在源拒绝使用经典证书进行身份验证的连接时才有帮助。