8.0
热点
AI SCORE
技术实践2026-09-13 18:33
后量子 TLS 是平台迁移，而非密码学项目
dev.to · AI#后量子加密#TLS#基础设施
Editor brief · 编辑速览
文章指出后量子 TLS 已进入主流云平台：AWS KMS/ACM/SecretsManager 支持 ML-KEM 混合模式，Cloudflare 和 Windows 已有落地实现，IETF TLS 1.3 的 ML-KEM 工作也在推进中，这是基础设施静默升级的典型路径。
关于后量子 TLS，最没用的讨论至今仍然最常见：
"量子计算机何时才能真正破解 RSA？"
我理解为什么人们会问这个问题。听起来像是负责任的问题，有倒计时的感觉，让每个人都可以争论物理学、国家实验室、密码学家，以及威胁是五年后还是十五年后的事。
但这也是一种逃避工程工作的简便方式——那些已经落到普通团队身上的工程工作。
后量子 TLS 不再只是标准议题或安全会议的 PPT。它正在成为平台层面的一部分。AWS 在 KMS、ACM 和 Secrets Manager 上支持 ML-KEM 混合 TLS。Cloudflare 记录了从访客到边缘节点、以及从边缘节点到源站的 post-quantum 密钥协商。Microsoft 已经出货了 Windows 平台对 ML-KEM 混合 TLS 组的支持和后量子 API。IETF 在 2026 年围绕 TLS 1.3 的 ML-KEM 工作非常活跃。
这就是基础设施变化通常到来的方式：不是戏剧性的切换，而是一系列安静的默认值。
有一天你的云提供商支持了新东西。然后一个 SDK 有一个标志。然后浏览器默认协商它。然后 CDN 可以用它与你的源站通信。然后一个老旧的中继设备、支付合作伙伴、服务网格、Java 运行时或证书工作流就成了图中的奇怪部分。
这就是迁移。
不是"量子是真的吗？"
而是"我们能证明哪些生产路径可以容忍新的 TLS 行为？"
狭义的技术变革不是什么魔法。
在 TLS 中，客户端和服务器已经协商如何就共享密钥达成一致。今天，这通常意味着椭圆曲线 Diffie-Hellman，其中 X25519 在现代 TLS 1.3 部署中很常见。后量子 TLS 引入了基于设计用来抵抗未来量子计算机攻击的算法的密钥协商。实际上，迁移通常是混合的：保留像 X25519 这样的经典算法，并将其与后量子密钥封装机制（如 ML-KEM）结合起来。
混合部分很重要。它意味着连接不是在全新的算法上孤注一掷。如果后量子方面出现意外，经典方面仍然保护你。后量子方面是为了解决"现在收集，以后解密"的问题：如果量子攻击对旧的密钥协商变得实用，今天捕获的加密流量以后会被解密。
运营层面的变化就不那么优雅了。
混合密钥交换改变了握手过程。它发送更多数据。它需要不同的 TLS 库支持。它可能暴露深度数据包检测、防火墙、代理、服务网格、负载均衡器和客户端中的 bug——那些对 TLS ClientHello 应该是什么样子做了假设的组件。
AWS 为其中一个 KMS 测试提供了真实数字：从经典 TLS 密钥协商迁移到 X25519 加 ML-KEM-768，TLS 握手增加了约 1,600 字节和额外的加密工作。在他们的基准测试中，使用连接复用时影响很小，没有使用时也不大。好。这正是你想要的结果。
但"AWS 测量的一条路径影响很小"不等于"你的生产图没问题。"
你的图有企业代理、sidecar、供应商 SDK、老旧 Android 设备、JVM 选项、证书检测设备、私有端点、支付处理器、银行集成、队列工作器、批处理作业，还有一台被遗忘的服务——它仍然认为 TLS 1.2 是现代的。
这才是真正的迁移所在。
一个容易混淆的简单方法是认为"后量子 TLS"是一次迁移。
它不是一次迁移。
密钥协商和认证是 TLS 的不同部分。混合 ML-KEM 密钥交换是为了保护会话密钥的机密性。后量子签名是为了认证：证明服务器或客户端是其声称的身份，而不依赖于 RSA 或 ECDSA 等经典签名方案。
这两部分在不同的时间线上推进，破坏的东西也不同。
Cloudflare 的文档使这种分离可见。对于密钥协商，它支持 X25519MLKEM768，当双方都能协商时，在 TLS 1.3 路径上有后量子混合密钥协商。对于签名，Cloudflare 在面向源站的功能上记录了 ML-DSA 支持，如 Authenticated Origin Pulls 和 Custom Origin Trust Store，并对 TLS 库、证书生成、信任存储和降级行为有明确要求。
这与启用客户端 TLS 组是非常不同的运营问题。
密钥交换问的是：客户端和服务器能否协商一个新的组，网络路径中的所有东西能否承受握手？
后量子证书问的是：我们的证书颁发机构、颁发流程、存储、轮换流程、mTLS 配置、信任存储、扫描器、HSM/KMS 工作流和验证代码能否处理新的签名算法和更大的产物？
这些应该一起规划，但不能合并成一个叫"启用 PQC"的工单。
那个工单会骗你。
现在值得关注的原因不是每个团队都必须在本季度切换每个后量子开关。
原因是默认值正在移动。
AWS 明确表达了方向：KMS、ACM 和 Secrets Manager 支持 ML-KEM 混合后量子 TLS，旧的 CRYSTALS-Kyber 支持正在被移除以支持 ML-KEM，客户负责更新客户端和 SDK 以便可以提供 ML-KEM。他们的 Java SDK 路径是具体的：使用 AWS Common Runtime HTTP 客户端并启用后量子 TLS 支持。Rust 有自己的路径，通过 rustls 功能标志。
这不是研究论文。这是依赖管理。
Cloudflare 的文档也不是抽象的。它们描述了后量子密钥协商在哪里工作，在哪里取决于客户端，在哪里取决于源站，以及 ML-DSA 证书在哪里改变源站认证行为。如果你把应用程序放在 CDN 后面，你的 TLS 边界已经在多个连接上分割了。访客到边缘，边缘到内部服务，边缘到源站。每段都可以有不同的就绪状态。
这就是为什么我不喜欢把后量子 TLS 当作安全团队的副业。
安全可以解释威胁模型和设置策略。密码学团队可以批准算法和库。但迁移路径贯穿平台工程、SRE、网络、客户端团队、构建管道、可观测性、供应商管理，以及谁负责那个没人想碰的支付集成。
如果安全独自承担一切，结果将是一份 PPT 和一个 backlog 标签。
互联网不是一次部署。
2026 年关于后量子就绪状态的测量工作调查了 32,011 个域名，发现了熟悉的现实形态：TLS 1.3 和 QUIC 等现代协议正在获得势头，但有意义的域名份额——尤其是银行和政府等关键行业——仍然依赖 TLS 1.2。
这对任何在金融基础设施附近工作的人来说都不应该惊讶。
银行技术栈充满了长期存在的集成。有些维护得很好。有些包裹在私有网络假设下。有些隐藏在托管网关后面。有些有与特定库或设备绑定的监管验证。有些使用在另一个时代设计的 TLS 终止模式，后来变得操作上太重要以至于不能轻易改变。
这并没有让银行疏忽。这让他们很正常。
这也意味着"提供商支持 PQ TLS"是工作的开始，不是结束。
在金融科技，你很少控制整个路径。你调用卡片处理器、欺诈供应商、身份提供商、KMS 端点、开放银行 API、webhook 接收器、核心银行适配器、文档处理器、分析工具和跨云跨区域的内部服务。这些路径中的每一条都有 TLS 客户端、TSL 服务器、库、代理、证书故事、监控故事和回滚故事。
如果你不能列出这些路径，你就无法迁移它们。
我对任何以"启用后量子 TLS"开始和结束的计划持怀疑态度。
通过哪些代理？
最低 TLS 版本是多少？
期望协商哪个组？
你怎么知道它协商成功了？
你怎么知道它降级了？
如果一个中继丢弃更大的 ClientHello 会发生什么？
哪些仪表板会显示"古典因为不支持"和"古典因为某些东西降级了"之间的区别？
回滚是什么？是功能标志、SDK 版本回滚、CDN 设置、JVM 属性、源站证书替换，还是网络异常？
这就是平台团队可以不做恐慌地做有用工作的地方。
从无聊的清单开始：
然后测试重要的路径。
不仅仅是来自带有新 OpenSSL 构建的笔记本电脑的快乐路径。测试生产形态的路径：相同的运行时、相同的容器基础镜像、相同的 SDK、相同的出站代理、相同的区域、相同的服务网格、相同的网关、相同的供应商端点类。
并适当给它加上检测。
对于后量子 TLS，"请求成功"是不够的。你想知道：
如果你无法观察协商，你主要是在猜测。
密钥交换迁移对许多团队来说是第一个可见的运营步骤，因为它可以被机会主义地协商。如果双方都支持混合组，就使用它。如果不支持，就回退。
证书和签名迁移就不那么宽容了。
后量子签名影响证书颁发、信任、兼容性、mTLS、扫描、轮换、存储，有时还有硬件支持的密钥管理。它们也引发降级问题。如果验证者在一个信任关系中同时接受后量子证书和经典证书，你实际上改善了认证故事，还是创造了一个旧风险仍然存在的漂亮演示？
Cloudflare 的源站文档是一个有用的例子，因为它清楚地说了那些不能说的话：如果验证端在同一认证路径中仍然接受经典证书，呈现后量子证书是不够的。
这不是密码学细节。这是策略。
团队应该分开这项工作：
第一步，为机密性映射和测试混合密钥交换。
第二步，确定签名真正重要的地方：公共 Web 证书、私有 PKI、服务间 mTLS、源站认证、代码签名、固件签名、文档签名，以及任何经典签名泄露有长期后果的工作流。
第三步，决定哪些证书路径可以是实验性的，哪些需要供应商支持，哪些被合规性、硬件或客户端阻塞。
试图在一个"后量子密码学迁移"的伞下解决所有这些，是让这项工作变得模糊以至于永远无法完成的方式。
这不是紧急动员的号召。这是停止把后量子 TLS 当作别人未来问题的号召。
有用的小检查清单是这样的：
提前做这些的团队不会看起来像英雄。他们只是会在默认值在他们脚下移动时少一些意外。
这就是真正的后量子 TLS 故事。
不是炒作。不是恐惧。不是量子末日的倒计时。
只是另一个平台迁移工作，如果你提供商的默认值改变之前开始，会容易得多；如果你等到生产路径替你发现边缘案例，会丑陋得多。
AWS Security Blog: ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager
AWS KMS Developer Guide: Using hybrid post-quantum TLS with AWS KMS
Cloudflare SSL/TLS docs: Post-quantum cryptography
Cloudflare SSL/TLS docs: Post-quantum between Cloudflare and origin servers
Microsoft Security Blog: New Windows Features to Secure Today's Data in a Post-Quantum World
IETF Datatracker: ML-KEM Post-Quantum Key Agreement for TLS 1.3
arXiv: Measurement Study of Post-Quantum Readiness of Internet: 2026