后量子 TLS 是平台迁移工程，不是密码学研究

在后量子密码学领域，最无意义的问题是"量子计算机什么时候到来？"

没有人能回答它——平台团队回答不了，标准组织也不会给出承诺，而且无论你得到什么数字，最终都会是错的。与此同时，迁移已经在你实际承载流量的地方悄然发生：云厂商默认配置、TLS 库、浏览器协商、CDN，以及那些你升级时从来不看发布说明的 SDK 版本。

这才是值得关注的重点。

后量子 TLS 已经不再是研究课题，而是平台工作。而平台工作有其熟悉的形态：资产清点、兼容性测试、可观测性、回滚。不是关于格密码学是否优美的是非题。

技术变革比营销炒作的更窄

值得精确地弄清楚实际上在发生什么变化，因为厂商的噪音把两个不同的问题混在了一起。

TLS 1.3 密钥协商正在转向混合模式。目前广泛部署的是 X25519MLKEM768：经典的椭圆曲线密钥交换与 ML-KEM 相结合，这样即使其中一个组件出问题，会话仍能保持安全。这部分目前正在浏览器、CDN、云 SDK 和操作系统中交付。

另一个问题是认证：后量子签名和证书、ML-DSA 及其同类方案，这些会改变你的 PKI、证书颁发机构、代码签名和硬件安全模块。这部分要早得多、也混乱得多，而且基本上不是你要在 2026 年解决的问题。

把这两者区分开是平台团队能做的第一件有用的事，因为它们的风险特征和时间线完全不同。混合密钥交换是配置和兼容性问题。后量子签名则是一个附带采购需求的 PKI 项目。

为什么它呈现为平台工作

下面这个模式让这件事变得具体而非抽象。

AWS 在 KMS、ACM 和 Secrets Manager 中支持 ML-KEM 混合后量子 TLS，并表示 CRYSTALS-Kyber 支持将在 2026 年内从 AWS 服务端点移除。这不是研究预览。这是会在你代码保持不变的情况下从你脚下移走的默认配置。

Cloudflare 记录了 TLS 1.3 的后量子密钥协商，以及边缘到源站指南——有趣的约束就在这里：你源站支持什么、你的代理代表你协商什么，以及混合握手在哪里会因为中间件或旧客户端无法处理而悄然回退到经典方案。

微软已经为 ML-KEM 混合 TLS 群组和 ML-DSA API 提供了 Windows 平台支持，并谈到在 2029 年前加速关键产品的迁移。

IETF 关于 TLS 1.3 中 ML-KEM 的工作正在活跃推进，已经足够接近可操作的实际状态，厂商正在基于它构建，而不仅仅是在幻灯片中引用。

而测量工作令人警醒。2026 年 6 月的一篇论文审视了超过 32,000 个域的后量子就绪情况，发现采用率在你预料中的地方参差不齐：银行业和政府中较旧的 TLS 1.2 端点、后量子证书支持薄弱，以及就绪程度与服务的安全关键程度并不成正比。

把这些放在一起看，结论不是"学习后量子密码学"。而是：在未来一两年内，你相当一部分出站连接将协商出与今天不同的密钥交换方式，有些会回退，有些会出问题，而你将从自己的遥测数据或一次事故中得知这一点。

没有人清点过的迁移面

问一个团队他们的哪些应用发出出站 TLS 连接，你会得到一个粗略的答案，只覆盖人们记得的服务。

那不是资产清单。那是一段记忆。

真正的清单包括：拥有自己 TLS 提供者的 JVM 密钥库、静态链接加密库的 Go 和 Rust 二进制文件、使用基础镜像自带 OpenSSL 的 Node 服务、2023 年以来没人升级过的 requests 库背后的 Python 客户端、数据库驱动程序、消息代理、Kafka 和 Redis 和 Postgres 客户端、自带 TLS 栈的服务网格边车、出口网关、正向代理、客户托管的负载均衡器、供应商支付 SDK、webhook 回调，以及那台跑着 cron 作业、与合作伙伴 API 通信的虚拟机。

然后把这些客户端经过的路径加上。一次握手不是发生在两个服务之间，而是发生在它们之间存在的任何东西之上，而中间件对数据包大小、TLS 扩展、连接重用和会话恢复都有看法。混合后量子 ClientHello 比经典的大，这恰恰是那种会在历史上找到"只用一个厂商的栈测试过"的设备的变化类型。

金融科技集成应该在电子表格中占一列。面向合作伙伴的 API 是你控制最少、变更窗口最长、意外成本最高的地方，也是另一方的就绪程度是你无法安排的依赖项。

真正要测量什么

直觉反应是打开开关看有没有东西坏掉。这在坏掉之前都管用。

有用的信号都是那些无聊的信号，而且大部分还没有出现在仪表板上：

每条路径协商出的密钥交换群组。不是库版本。是握手实际得出的群组，按客户端、目的地和时间拆分。没有这个，你就无法回答"它混合了还是悄无声息地回退了？"

握手大小和完成率。追踪握手字节数，而不仅仅是延迟。有些失败表现为重试和超时，而不是错误，而凌晨 3 点的重试风暴看起来完全不像 TLS 回归问题，直到你去查看。

加密路径上的 CPU 成本。ML-KEM 不是免费的，session 建立才是它落脚的地方。如果你每连接的 CPU 预算紧张，这是一个伪装成安全升级的容量变化。

回退计数，按对端分。回退不是失败，但是一个你应该能够计数、归属和解释的事实。

证书和信任变更分开追踪。把签名迁移排除在密钥交换推出之外，这样当东西坏掉时，你知道是哪个变更导致的。

如果这些今天都不存在，那么后量子项目的第一个交付物不是 TLS 配置，而是一套能够证明协商结果的遥测能力。

"打开开关"不是策略

这是持怀疑态度的部分，也是我认为这属于平台待办事项而非仅仅属于安全待办事项的原因。

这类迁移都遵循相同的轨迹。厂商启用了一个聪明的默认配置，SDK 升级带入了新的 TLS 栈，CDN 翻转了混合密钥协商的优先级，流量开始以不同方式协商。最好的情况是什么都没变，每个人都继续前进。常见的情况是，一部分连接回退了，更小的一部分失败了，而"安全"与"看起来能工作"之间的差异是一套没人埋点的诊断。

这与我们见过的证书过期、密码套件弃用和 DNS 变更的失败模式相同。技术上的变更很小，运营上却看不见，这是最糟糕的组合，因为这意味着唯一的信号是客户影响。

能够顺利度过这一关的团队不会是首批部署 ML-KEM 的团队。他们是那些在任何一天都能说出：他们的哪些连接使用了混合群组、哪些没有、哪条路径出了问题、以及如果答案隔夜变了会发生什么。

一份不需要恐慌的清单

如果我来操盘这件事，我会按这个顺序从这里开始。

按负责人清点出站 TLS 客户端，而非按主机名。每个打开 TLS 连接的服务、作业和脚本，以及负责它们的团队。按语言运行时和 TLS 提供者分组，因为那才是决定升级成本的因素。

绘制路径图，而不仅仅是端点。对于每个关键依赖项，列出它们之间存在的东西：代理、网关、网格、CDN、合作伙伴设备。路径才是兼容性意外栖息的地方。

在任何变更之前先埋点协商出的群组。如果没有 rollout 前的基础数据，你就无法声称成功或检测回归。

在一条路径族上用启用了混合密钥交换偏好的配置进行试点。先从无聊的内部路径开始，然后是与有真实变更窗口的合作伙伴集成的那个。

排练回滚。知道如何强制每条路径回退，并在还有时间犯错的时候测试它。

把签名和信任工作流分开。追踪它、资助它，但不要把它与密钥交换 rollout 混在一起。这是一个 PKI 项目，会更慢。

写下来谁负责。后量子 TLS 如果属于"安全"这个泛泛的类别，就等于没有具体负责人，只会在事故中被重新发现。

这些都不稀奇。这与任何其他跨领域平台变更的纪律相同，只不过应用于一个通过默认配置而非项目计划到来的变更。

AWS Security Blog: ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager

AWS KMS Developer Guide: Post-quantum TLS for AWS KMS

Cloudflare Docs: Post-quantum cryptography

Cloudflare Docs: Post-quantum cryptography to origin

Microsoft Security Blog: New Windows features to secure today's data in a post-quantum world

IETF: ML-KEM for TLS 1.3 draft

arXiv: Measurement Study of Post-Quantum Readiness of Internet: 2026

To test my projects, I use Railway. If you want $20 USD to get started, use this link.