后量子身份验证现已支持
Cloudflare 的身份验证源拉取和自定义来源信任库现在支持后量子身份验证。
在这里，我们将解释如何配置完全后量子安全的双向身份验证 TLS 连接到您的源服务器，深入探讨我们构建它的工程细节，做一个羞怯的 confession，最后解释这项工作如何适应我们整体的后量子迁移路线图。
## 达到重要的里程碑
我们过去几年的重点是部署后量子 [加密](https://radar.cloudflare.com/post-quantum) 以防御 [收集-现在，稍后解密](https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later) 攻击，即攻击者悄悄储存您的加密数据，希望将来能通过量子计算机解密它。
然而，量子计算和密码分析的最新突破将升级到后量子密码学的时间表提前到了 [行业](https://www.microsoft.com/en-us/security/blog/2026/06/30/microsoft-advances-quantum-safe-security-as-the-risk-timeline-shifts/) 和 [政府](https://blog.cloudflare.com/post-quantum-eo-2026/) 的前沿，我们的注意力因此转向部署后量子 *身份验证*，以保护免受攻击者的威胁，他们很快就能使用量子计算机破解经典凭证并进行冒充攻击。
在之前的帖子中，我们宣布 Cloudflare 的目标是 [2029 年](https://blog.cloudflare.com/post-quantum-roadmap/#cloudflares-roadmap-to-full-post-quantum-security) 达成全面后量子安全，并列出了几个里程碑。我们已经达到了第一个里程碑：我们的 [身份验证源拉取](https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/) 和 [自定义来源信任库](https://developers.cloudflare.com/ssl/origin-configuration/custom-origin-trust-store/) 产品 [现在支持后量子 (PQ) 身份验证](https://developers.cloudflare.com/changelog/post/2026-06-17-pqc-mldsa-aop-cots/) ，采用基于模块的格算法 (ML-DSA) 签名来保护 Cloudflare 与客户源服务器之间的连接。
## 源连接的不同
当客户访问通过 Cloudflare 代理的网站时，通常涉及两条连接。第一条连接是来自访问者（例如，浏览器）到 Cloudflare。如果请求可以从 Cloudflare 的缓存中服务或触发任何阻止规则，Cloudflare 可能会直接响应。否则，Cloudflare 将建立第二条连接到客户的源服务器以获取请求的内容，以便它可以响应原始请求。
保护敏感访客数据需要这两条连接在量子攻击下都能保持安全。我们在 [2022](https://blog.cloudflare.com/post-quantum-for-all/) 年启用访问者到 Cloudflare（连接 1）和 Cloudflare 到源（连接 2）两条连接的后量子加密支持，并已经看到了 [显著使用](https://radar.cloudflare.com/post-quantum)。
我们正在积极努力完成后量子身份验证的全景。对于访问者到 Cloudflare 的连接，我们正在与 [Google](https://blog.google/security/cultivating-a-robust-and-efficient-quantum-safe-https/) 及其他人合作，开发和 [实验](https://blog.cloudflare.com/bootstrap-mtc) 梅克尔树证书 [（MTC）](https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/)，旨在为网络提供快速的后量子证书，初步部署目标为 2027 年。然而，本文的话题是 Cloudflare 到源的连接，其身份验证的要求在几个重要方面与访问者到 Cloudflare 的连接不同。
对于此连接，Cloudflare 是客户端。这使我们能够采用连接池等技术，将来自我们网络各地的请求汇聚到一组更小的源服务器连接上，从而将连接设置的开销分摊到许多请求中。这使得“可直接使用”的后量子签名成本更易承受，而 MTC 的性能优势则显得不那么必要。
由于 Cloudflare 与客户之间存在预先的信任关系（即，Cloudflare 账户），我们不需要与公共互联网的公钥基础设施（PKI）[（WebPKI）](https://cabforum.org/working-groups/server/baseline-requirements/requirements/) 的限制和时间表挂钩，而是可以使用针对使用案例量身定制的自定义 PKI，而不必受到可能不适用的中间证书和 [证书透明性](https://datatracker.ietf.org/doc/html/rfc6962) 的干扰。像 [Cloudflare Tunnel](https://developers.cloudflare.com/tunnel/) 这样的解决方案也可用于保护 Cloudflare 到源的连接，而无需升级传统源系统，通过在安全的后量子加密（即后量子身份验证正在推进）下转发流量。
所有这些说，Cloudflare 到源连接的独特要求使我们能够在 WebPKI 进入公共互联网之前优先部署基于 ML-DSA 的后量子身份验证。（对于仍然坚持使用 WebPKI 的客户，不用担心：我们将在未来为 Cloudflare 到源的连接添加 MTC 支持。）
那么，如何开启这个功能呢？让我们深入配置。
## 配置完全 PQ 安全的源连接
我们已在自定义来源信任库和身份验证源拉取产品中添加了 ML-DSA 支持（支持所有 [FIPS 204](https://csrc.nist.gov/pubs/fips/204/final) 参数集：ML-DSA-44、ML-DSA-65 和 ML-DSA-87）。我们推荐大部分应用使用 ML-DSA-44，因为它是性能最佳的选项，并获得了舒适的 NIST [第 2 类](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf#page=25) 安全强度。
### 自定义来源信任库
当 Cloudflare 以 [完全 (严格)](https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/full-strict/) SSL 模式连接至配置好的客户源服务器时，我们会对源证书进行身份验证，默认信任库包含所有 [常见的信任](https://ccadb.org) 证书颁发机构 (CAs) 以及 Cloudflare 的 [源 CA](https://developers.cloudflare.com/ssl/origin-configuration/origin-ca/)。自定义来源信任库 (COTS) 产品（需要启用 [高级证书管理器](https://developers.cloudflare.com/ssl/edge-certificates/advanced-certificate-manager/)）允许客户用他们控制的 CA 替换此默认信任库。COTS 现在允许客户上传 ML-DSA CA，因此当 Cloudflare 连接到源时，它将信任任何源服务器证书链路到该 CA。
### 身份验证源拉取
为了限制对源服务器的滥用和资源消耗，客户可能希望仅服务来自 Cloudflare 服务器的请求。 [身份验证源拉取 (AOP)](https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/) 可用于配置 Cloudflare 向源服务器呈现客户端证书，以建立一个 [双向 TLS (mTLS)](https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/) 连接，在该连接中，双方之间的通信都是双向安全和可信的。AOP 在所有 Cloudflare 计划级别上免费提供。
AOP 支持三种 [配置级别](https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/#configuration-levels)：全局、每个区域和每个主机名。每个区域和每个主机名的配置级别现在允许客户上传 ML-DSA 证书和私钥（以 FIPS 204 种子格式），以便 Cloudflare 的 TLS 客户端会在连接到源服务器时呈现此证书以进行身份验证。（别担心，我们没有忘记全局配置级别——这只是一个更复杂的变更，我们将在稍后优先处理。）
### 避免降级
为身份验证和验证双方添加后量子加密和身份验证支持是必要的，但仅此并不足以保证完全的后量子安全。棘手的降级问题依然存在。如果验证方支持任何易受量子攻击的身份验证机制，它们仍然易受到 [路径攻击者](https://www.cloudflare.com/learning/security/threats/on-path-attack/) 的攻击，可以伪造经典凭证。
修复方法是：验证方必须去除对易受量子攻击的身份验证机制的信任。（这在复杂的 PKI 中更为细致。例如，查看 Chrome 安全团队的 [四个阶段计划](https://www.chromium.org/Home/chromium-security/post-quantum-auth-roadmap/) 以便于过渡到网络。）有关如何确保您的源防范降级攻击的详细信息，请参见 AOP 和 COTS 的 [配置指南](https://developers.cloudflare.com/ssl/post-quantum-cryptography/pqc-to-origin/#avoid-downgrades)。
### 快速开始
下面的指南展示了如何生成 ML-DSA 证书链并通过 Cloudflare API 配置这两个产品。有关仪表板说明和额外上下文，请参考 [开发文档](https://developers.cloudflare.com/ssl/post-quantum-cryptography/pqc-to-origin/)。
1. 生成证书
您需要 OpenSSL 3.5.0 或更高版本。私钥必须采用 FIPS 204 种子仅编码生成，这是 Cloudflare 当前接受的唯一上传格式。
**应用于 COTS 的源服务器证书链：**
**适用于 AOP 的 Cloudflare 客户端证书链：**
2. 上传源 CA 到自定义来源信任库
上传 COTS CA 将替换区域的默认公开信任 CA。确保您仅在希望避免降级攻击时上传后量子 CA。
3. 上传用于身份验证源拉取的客户端证书
示例如下，使用区域级 AOP。如果您更喜欢主机名 AOP，请改用 `/origin_tls_client_auth/hostnames/certificates` 端点。
4. 将您的 SSL/TLS 模式设置为完全 (严格)
自定义来源信任库仅在您的区域使用 **完全 (严格)** 模式下激活。如果您在没有 COTS 的情况下使用 AOP，则 **完全** 或更高模式足够。
5. 配置您的源服务器 (在 NGINX 上)
如果您使用 COTS（您的源呈现 ML-DSA 服务器证书）：
如果您使用 AOP（您的源验证 Cloudflare 的客户端证书）：
如果您同时使用这两者（推荐用于全面后量子双向 TLS）：
6. 验证后量子握手
Cloudflare 与您的源之间的 TLS 握手在幕后发生，因此您无法通过从外部连接到您的代理主机名直接观察它。相反，请分别验证每一方。
**验证 COTS（源呈现 ML-DSA 证书）：**
如果您的源 IP 直接可达（例如，在启用 Cloudflare 代理之前的测试），直接连接到源 IP 并验证证书：
如果您的源被防火墙限制为仅接收 Cloudflare IP，请检查您的源服务器的 TLS 日志或使用诸如 `ssldump` 或 `tcpdump` 之类的包捕获工具，确认 Cloudflare 使用 ML-DSA 证书协商了 TLS 1.3。
**验证 AOP（Cloudflare 提供客户端证书）：**
确保对源的直接连接（没有有效客户证书）被拒绝：
在启用 `ssl_verify_client` 的情况下，这应当因 SSL 警报而失败。
**验证完整的 Cloudflare 到源路径：**
由于 mTLS 握手发生在服务器与服务器之间，确认 Cloudflare 正在呈现 ML-DSA 客户端证书的最可靠方法是检查您的源服务器日志。例如，在 NGINX 中，您可以记录客户端证书的序列号或主题：
在通过 Cloudflare 发送请求后，检查日志。您应该能看到上传的 `aop-client.crt` 证书的序列号。
对于密钥协商，请确保您的源的 TLS 库支持 `X25519MLKEM768` 并在您的配置中优先考虑。后量子密钥协商将在源服务器日志或数据包捕获中显示为协商组。
## 无聊的细节
实现此功能涉及两个主要系统：我们控制平面服务，允许客户管理他们的 TLS 设置和上传证书，以及负责根据客户配置与源服务器建立 TLS 连接的数据平面服务。
### 控制平面
和其他许多为 Cloudflare 的 API 和仪表板提供动力的服务一样，用于 Cloudflare 的 [SSL/TLS 产品](https://developers.cloudflare.com/ssl/) 配置的服务在一组关键数据中心中运行着一个 [高可用设置](https://blog.cloudflare.com/major-data-center-power-failure-again-cloudflare-code-orange-tested/)。该服务负责处理 SSL/TLS 设置更新并将其推送到我们的 [全球分布的键值存储](https://blog.cloudflare.com/quicksilver-v2-evolution-of-a-globally-distributed-key-value-store-part-1/)，以供数据平面服务在处理实时请求时使用。
启用 ML-DSA 对 AOP 和 COTS 的支持需要更新此服务，以支持解析和验证 ML-DSA 证书。这听起来在纸面上简单，但有个问题：该服务是用 Go 编写的，但 Go 的标准 X.509 和 TLS 库尚未支持 ML-DSA。我们在 Cloudflare 的 [CIRCL](https://blog.cloudflare.com/introducing-circl/) [库](https://github.com/cloudflare/circl) 中实施了 [必要功能](https://github.com/cloudflare/circl/pull/559) 来修补支持。这是一个相对简单的更改，但要对每个需要后量子身份验证支持的服务重复此操作将是一项重大工作。
幸运的是，预期于 2026 年 8 月发布的 [Go 1.27](https://go.dev/doc/go1.27) 将包括本机 ML-DSA 支持，并允许我们删除 CIRCL 依赖。其他基于 Go 的服务随后将能够通过简单的版本更新无缝引入 ML-DSA 支持。
### 数据平面
在控制平面的变更到位后，客户可以为 AOP 和 COTS 产品上传 ML-DSA 证书。下一步是更新我们负责与客户源交互的数据平面服务以实际使用这些证书。
我们在之前的博文中谈及过我们开源的代理框架 [Pingora](https://blog.cloudflare.com/pingora-open-source/) ，尤其是我们有一个基于 Pingora 的服务用于处理所有与源的连接。该服务名叫 [Pingora Origin](https://blog.cloudflare.com/pingora-saving-compute-1-percent-at-a-time/#motivation)，负责确保每秒数百万个请求的源绑定请求安全且可靠地到达最终目的地。
确保请求的安全性通常归诸于 TLS 提供者，您可能会感到惊讶的是，后量子安全（在这种情况下为真实性）没有什么不同。也许令人失望的是，防御量子攻击并不需要带有激光和超导的奇特物质状态；您所需要的只是将 [BoringSSL](https://github.com/google/boringssl) 更新到最新版本。如今，BoringSSL 在过去几年中，没有 CVEs 或重大的变化。事实上，我们对这种稳定性的依赖如此之深，以至于我们必须承认，我们已经将 Pingora Origin 更新到 BoringSSL 的工作推迟了四年，而是保持了一个内部分支以在需要时增加附加功能。虽然这工作得很好，但后量子身份验证支持的更新
---
原文链接：[点击查看](https://blog.cloudflare.com/post-quantum-authentication-to-origins/)
在这里，我们将解释如何配置完全后量子安全的双向身份验证 TLS 连接到您的源服务器，深入探讨我们构建它的工程细节，做一个羞怯的 confession，最后解释这项工作如何适应我们整体的后量子迁移路线图。
## 达到重要的里程碑
我们过去几年的重点是部署后量子 [加密](https://radar.cloudflare.com/post-quantum) 以防御 [收集-现在，稍后解密](https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later) 攻击，即攻击者悄悄储存您的加密数据，希望将来能通过量子计算机解密它。
然而，量子计算和密码分析的最新突破将升级到后量子密码学的时间表提前到了 [行业](https://www.microsoft.com/en-us/security/blog/2026/06/30/microsoft-advances-quantum-safe-security-as-the-risk-timeline-shifts/) 和 [政府](https://blog.cloudflare.com/post-quantum-eo-2026/) 的前沿，我们的注意力因此转向部署后量子 *身份验证*，以保护免受攻击者的威胁，他们很快就能使用量子计算机破解经典凭证并进行冒充攻击。
在之前的帖子中，我们宣布 Cloudflare 的目标是 [2029 年](https://blog.cloudflare.com/post-quantum-roadmap/#cloudflares-roadmap-to-full-post-quantum-security) 达成全面后量子安全，并列出了几个里程碑。我们已经达到了第一个里程碑：我们的 [身份验证源拉取](https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/) 和 [自定义来源信任库](https://developers.cloudflare.com/ssl/origin-configuration/custom-origin-trust-store/) 产品 [现在支持后量子 (PQ) 身份验证](https://developers.cloudflare.com/changelog/post/2026-06-17-pqc-mldsa-aop-cots/) ，采用基于模块的格算法 (ML-DSA) 签名来保护 Cloudflare 与客户源服务器之间的连接。
## 源连接的不同
当客户访问通过 Cloudflare 代理的网站时，通常涉及两条连接。第一条连接是来自访问者（例如，浏览器）到 Cloudflare。如果请求可以从 Cloudflare 的缓存中服务或触发任何阻止规则，Cloudflare 可能会直接响应。否则，Cloudflare 将建立第二条连接到客户的源服务器以获取请求的内容，以便它可以响应原始请求。
保护敏感访客数据需要这两条连接在量子攻击下都能保持安全。我们在 [2022](https://blog.cloudflare.com/post-quantum-for-all/) 年启用访问者到 Cloudflare（连接 1）和 Cloudflare 到源（连接 2）两条连接的后量子加密支持，并已经看到了 [显著使用](https://radar.cloudflare.com/post-quantum)。
我们正在积极努力完成后量子身份验证的全景。对于访问者到 Cloudflare 的连接，我们正在与 [Google](https://blog.google/security/cultivating-a-robust-and-efficient-quantum-safe-https/) 及其他人合作，开发和 [实验](https://blog.cloudflare.com/bootstrap-mtc) 梅克尔树证书 [（MTC）](https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/)，旨在为网络提供快速的后量子证书，初步部署目标为 2027 年。然而，本文的话题是 Cloudflare 到源的连接，其身份验证的要求在几个重要方面与访问者到 Cloudflare 的连接不同。
对于此连接，Cloudflare 是客户端。这使我们能够采用连接池等技术，将来自我们网络各地的请求汇聚到一组更小的源服务器连接上，从而将连接设置的开销分摊到许多请求中。这使得“可直接使用”的后量子签名成本更易承受，而 MTC 的性能优势则显得不那么必要。
由于 Cloudflare 与客户之间存在预先的信任关系（即，Cloudflare 账户），我们不需要与公共互联网的公钥基础设施（PKI）[（WebPKI）](https://cabforum.org/working-groups/server/baseline-requirements/requirements/) 的限制和时间表挂钩，而是可以使用针对使用案例量身定制的自定义 PKI，而不必受到可能不适用的中间证书和 [证书透明性](https://datatracker.ietf.org/doc/html/rfc6962) 的干扰。像 [Cloudflare Tunnel](https://developers.cloudflare.com/tunnel/) 这样的解决方案也可用于保护 Cloudflare 到源的连接，而无需升级传统源系统，通过在安全的后量子加密（即后量子身份验证正在推进）下转发流量。
所有这些说，Cloudflare 到源连接的独特要求使我们能够在 WebPKI 进入公共互联网之前优先部署基于 ML-DSA 的后量子身份验证。（对于仍然坚持使用 WebPKI 的客户，不用担心：我们将在未来为 Cloudflare 到源的连接添加 MTC 支持。）
那么，如何开启这个功能呢？让我们深入配置。
## 配置完全 PQ 安全的源连接
我们已在自定义来源信任库和身份验证源拉取产品中添加了 ML-DSA 支持（支持所有 [FIPS 204](https://csrc.nist.gov/pubs/fips/204/final) 参数集：ML-DSA-44、ML-DSA-65 和 ML-DSA-87）。我们推荐大部分应用使用 ML-DSA-44，因为它是性能最佳的选项，并获得了舒适的 NIST [第 2 类](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf#page=25) 安全强度。
### 自定义来源信任库
当 Cloudflare 以 [完全 (严格)](https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/full-strict/) SSL 模式连接至配置好的客户源服务器时，我们会对源证书进行身份验证，默认信任库包含所有 [常见的信任](https://ccadb.org) 证书颁发机构 (CAs) 以及 Cloudflare 的 [源 CA](https://developers.cloudflare.com/ssl/origin-configuration/origin-ca/)。自定义来源信任库 (COTS) 产品（需要启用 [高级证书管理器](https://developers.cloudflare.com/ssl/edge-certificates/advanced-certificate-manager/)）允许客户用他们控制的 CA 替换此默认信任库。COTS 现在允许客户上传 ML-DSA CA，因此当 Cloudflare 连接到源时，它将信任任何源服务器证书链路到该 CA。
### 身份验证源拉取
为了限制对源服务器的滥用和资源消耗，客户可能希望仅服务来自 Cloudflare 服务器的请求。 [身份验证源拉取 (AOP)](https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/) 可用于配置 Cloudflare 向源服务器呈现客户端证书，以建立一个 [双向 TLS (mTLS)](https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/) 连接，在该连接中，双方之间的通信都是双向安全和可信的。AOP 在所有 Cloudflare 计划级别上免费提供。
AOP 支持三种 [配置级别](https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/#configuration-levels)：全局、每个区域和每个主机名。每个区域和每个主机名的配置级别现在允许客户上传 ML-DSA 证书和私钥（以 FIPS 204 种子格式），以便 Cloudflare 的 TLS 客户端会在连接到源服务器时呈现此证书以进行身份验证。（别担心，我们没有忘记全局配置级别——这只是一个更复杂的变更，我们将在稍后优先处理。）
### 避免降级
为身份验证和验证双方添加后量子加密和身份验证支持是必要的，但仅此并不足以保证完全的后量子安全。棘手的降级问题依然存在。如果验证方支持任何易受量子攻击的身份验证机制，它们仍然易受到 [路径攻击者](https://www.cloudflare.com/learning/security/threats/on-path-attack/) 的攻击，可以伪造经典凭证。
修复方法是：验证方必须去除对易受量子攻击的身份验证机制的信任。（这在复杂的 PKI 中更为细致。例如，查看 Chrome 安全团队的 [四个阶段计划](https://www.chromium.org/Home/chromium-security/post-quantum-auth-roadmap/) 以便于过渡到网络。）有关如何确保您的源防范降级攻击的详细信息，请参见 AOP 和 COTS 的 [配置指南](https://developers.cloudflare.com/ssl/post-quantum-cryptography/pqc-to-origin/#avoid-downgrades)。
### 快速开始
下面的指南展示了如何生成 ML-DSA 证书链并通过 Cloudflare API 配置这两个产品。有关仪表板说明和额外上下文，请参考 [开发文档](https://developers.cloudflare.com/ssl/post-quantum-cryptography/pqc-to-origin/)。
1. 生成证书
您需要 OpenSSL 3.5.0 或更高版本。私钥必须采用 FIPS 204 种子仅编码生成，这是 Cloudflare 当前接受的唯一上传格式。
**应用于 COTS 的源服务器证书链：**
**适用于 AOP 的 Cloudflare 客户端证书链：**
2. 上传源 CA 到自定义来源信任库
上传 COTS CA 将替换区域的默认公开信任 CA。确保您仅在希望避免降级攻击时上传后量子 CA。
3. 上传用于身份验证源拉取的客户端证书
示例如下，使用区域级 AOP。如果您更喜欢主机名 AOP，请改用 `/origin_tls_client_auth/hostnames/certificates` 端点。
4. 将您的 SSL/TLS 模式设置为完全 (严格)
自定义来源信任库仅在您的区域使用 **完全 (严格)** 模式下激活。如果您在没有 COTS 的情况下使用 AOP，则 **完全** 或更高模式足够。
5. 配置您的源服务器 (在 NGINX 上)
如果您使用 COTS（您的源呈现 ML-DSA 服务器证书）：
如果您使用 AOP（您的源验证 Cloudflare 的客户端证书）：
如果您同时使用这两者（推荐用于全面后量子双向 TLS）：
6. 验证后量子握手
Cloudflare 与您的源之间的 TLS 握手在幕后发生，因此您无法通过从外部连接到您的代理主机名直接观察它。相反，请分别验证每一方。
**验证 COTS（源呈现 ML-DSA 证书）：**
如果您的源 IP 直接可达（例如，在启用 Cloudflare 代理之前的测试），直接连接到源 IP 并验证证书：
如果您的源被防火墙限制为仅接收 Cloudflare IP，请检查您的源服务器的 TLS 日志或使用诸如 `ssldump` 或 `tcpdump` 之类的包捕获工具，确认 Cloudflare 使用 ML-DSA 证书协商了 TLS 1.3。
**验证 AOP（Cloudflare 提供客户端证书）：**
确保对源的直接连接（没有有效客户证书）被拒绝：
在启用 `ssl_verify_client` 的情况下，这应当因 SSL 警报而失败。
**验证完整的 Cloudflare 到源路径：**
由于 mTLS 握手发生在服务器与服务器之间，确认 Cloudflare 正在呈现 ML-DSA 客户端证书的最可靠方法是检查您的源服务器日志。例如，在 NGINX 中，您可以记录客户端证书的序列号或主题：
在通过 Cloudflare 发送请求后，检查日志。您应该能看到上传的 `aop-client.crt` 证书的序列号。
对于密钥协商，请确保您的源的 TLS 库支持 `X25519MLKEM768` 并在您的配置中优先考虑。后量子密钥协商将在源服务器日志或数据包捕获中显示为协商组。
## 无聊的细节
实现此功能涉及两个主要系统：我们控制平面服务，允许客户管理他们的 TLS 设置和上传证书，以及负责根据客户配置与源服务器建立 TLS 连接的数据平面服务。
### 控制平面
和其他许多为 Cloudflare 的 API 和仪表板提供动力的服务一样，用于 Cloudflare 的 [SSL/TLS 产品](https://developers.cloudflare.com/ssl/) 配置的服务在一组关键数据中心中运行着一个 [高可用设置](https://blog.cloudflare.com/major-data-center-power-failure-again-cloudflare-code-orange-tested/)。该服务负责处理 SSL/TLS 设置更新并将其推送到我们的 [全球分布的键值存储](https://blog.cloudflare.com/quicksilver-v2-evolution-of-a-globally-distributed-key-value-store-part-1/)，以供数据平面服务在处理实时请求时使用。
启用 ML-DSA 对 AOP 和 COTS 的支持需要更新此服务，以支持解析和验证 ML-DSA 证书。这听起来在纸面上简单，但有个问题：该服务是用 Go 编写的，但 Go 的标准 X.509 和 TLS 库尚未支持 ML-DSA。我们在 Cloudflare 的 [CIRCL](https://blog.cloudflare.com/introducing-circl/) [库](https://github.com/cloudflare/circl) 中实施了 [必要功能](https://github.com/cloudflare/circl/pull/559) 来修补支持。这是一个相对简单的更改，但要对每个需要后量子身份验证支持的服务重复此操作将是一项重大工作。
幸运的是，预期于 2026 年 8 月发布的 [Go 1.27](https://go.dev/doc/go1.27) 将包括本机 ML-DSA 支持，并允许我们删除 CIRCL 依赖。其他基于 Go 的服务随后将能够通过简单的版本更新无缝引入 ML-DSA 支持。
### 数据平面
在控制平面的变更到位后，客户可以为 AOP 和 COTS 产品上传 ML-DSA 证书。下一步是更新我们负责与客户源交互的数据平面服务以实际使用这些证书。
我们在之前的博文中谈及过我们开源的代理框架 [Pingora](https://blog.cloudflare.com/pingora-open-source/) ，尤其是我们有一个基于 Pingora 的服务用于处理所有与源的连接。该服务名叫 [Pingora Origin](https://blog.cloudflare.com/pingora-saving-compute-1-percent-at-a-time/#motivation)，负责确保每秒数百万个请求的源绑定请求安全且可靠地到达最终目的地。
确保请求的安全性通常归诸于 TLS 提供者，您可能会感到惊讶的是，后量子安全（在这种情况下为真实性）没有什么不同。也许令人失望的是，防御量子攻击并不需要带有激光和超导的奇特物质状态；您所需要的只是将 [BoringSSL](https://github.com/google/boringssl) 更新到最新版本。如今，BoringSSL 在过去几年中，没有 CVEs 或重大的变化。事实上，我们对这种稳定性的依赖如此之深，以至于我们必须承认，我们已经将 Pingora Origin 更新到 BoringSSL 的工作推迟了四年，而是保持了一个内部分支以在需要时增加附加功能。虽然这工作得很好，但后量子身份验证支持的更新
---
原文链接：[点击查看](https://blog.cloudflare.com/post-quantum-authentication-to-origins/)
评论
暂无评论。