后量子 TLS：2026 年抗量子 HTTPS 意味着什么

2026-06-02

post-quantumpqcml-kemtlsencryptionsecurity

后量子 TLS 是即使面对拥有大型量子计算机的攻击者也能保持安全的 HTTPS。它用专门设计来抵抗量子攻击的算法，替换了当今密钥交换背后那套——量子计算机可能破解的——数学难题。

这并非遥远的研究项目。截至 2026 年年中，通过 Cloudflare 的真人网络流量中，已有超过 65% 经过后量子加密，而 Chrome、Edge 和 Firefox 只要服务器支持，就会默认协商抗量子密钥交换。如果你最近用现代浏览器访问过 Google，几乎可以肯定你已经在不知不觉中用上了后量子 TLS。

为什么经典 TLS 面临风险

当今的 TLS 依赖两类公钥数学：

密钥交换（ECDHE，使用 X25519 或 P-256）——在公开信道上协商出一个共享密钥。
签名（RSA、ECDSA）——证明证书的真实性。

两者都依赖对经典计算机而言困难的问题——大数分解（RSA）和椭圆曲线离散对数（ECC）。Shor 算法在足够大的量子计算机上运行，可以高效地解决这两类问题。“密码学相关量子计算机”（CRQC）目前尚不存在，但该领域的发展速度已经让规划从”是否会”转向了”何时会”。

公钥密码学 → 解释了量子计算机所威胁的底层数学。

“先收集后解密”——为什么今天就要紧迫应对

你可能会想：不急吧，今天没有量子计算机能破解 TLS，何必现在就切换？

威胁在于先收集后解密（harvest now, decrypt later，HNDL）。攻击者今天就把你的加密流量录下来存好，等到将来——可能是 2030 年代——量子计算机就绪后，再回溯性地解密这些存储的流量。

这使得密钥交换的截止期限远早于量子计算机的到来。任何保密期较长的数据——医疗记录、金融数据、政府机密、源代码、凭据——都需要现在就用抗量子加密，因为录制行为已经在进行了。

密钥交换很紧迫，签名则不那么紧迫。 你无法对已经发生的流量回溯性地伪造签名——签名只需要在量子计算机出现之前做到抗量子即可。这正是业界先部署后量子密钥交换的原因。

标准：ML-KEM 与 ML-DSA

2024 年 8 月，NIST 发布了首批最终确定的后量子标准：

标准	名称	作用	替代对象
FIPS 203	ML-KEM（前身 Kyber）	密钥封装（密钥交换）	ECDHE / RSA 密钥交换
FIPS 204	ML-DSA（前身 Dilithium）	数字签名	RSA / ECDSA 签名
FIPS 205	SLH-DSA（SPHINCS+）	基于哈希的签名	保守的签名备选方案

ML-KEM（模格密钥封装机制）就是已经在 TLS 中部署的那个。它有三种规格：ML-KEM-512、ML-KEM-768 和 ML-KEM-1024。ML-KEM-768 是网络上使用的最佳平衡点。

混合密钥交换：X25519MLKEM768

浏览器不会一夜之间抛弃经典密码学、直接切到纯后量子。那太鲁莽了——ML-KEM 还很新，一旦有缺陷就会满盘皆输。取而代之，TLS 1.3 使用一种把经典算法与后量子算法结合起来的混合密钥交换。

2026 年你会看到的命名组是 X25519MLKEM768：

X25519MLKEM768 = X25519（经典 ECDHE）  +  ML-KEM-768（后量子）

两个共享密钥被拼接在一起（X25519 的 32 字节 + ML-KEM 的 32 字节 = 64 字节的组合密钥），再喂入 TLS 密钥派生流程。

安全保证是**“任一成立即安全”**。攻击者必须同时破解 X25519 和 ML-KEM-768 才能恢复会话密钥。因此：

如果 ML-KEM-768 被发现有缺陷 → X25519 仍然保护你（对抗经典攻击者）。
如果量子计算机破解了 X25519 → ML-KEM-768 仍然保护你。

正是这种双保险设计，让混合方案成为处处采用的默认选项，而非纯后量子。

它在握手中的位置

混合密钥交换使用什么是 TLS 1.3 → 中描述的同一套 TLS 1.3 握手。唯一的区别在于 key_share：ClientHello 携带的是 X25519MLKEM768 密钥份额，而非普通的 X25519。ML-KEM 的密钥更大（约 1.2 KB，而非 32 字节），所以 ClientHello 会增大约一千字节——通常可以忽略，但在受限网络上偶尔会跨越数据包边界。

它同样为你提供前向保密 →：每次连接生成全新的密钥对，后量子版本。

2026 年已经部署的部分

组件	后量子状态（2026 年年中）
Chrome / Edge	默认协商 X25519MLKEM768
Firefox	已支持并启用 X25519MLKEM768
Cloudflare	65%+ 真人流量已后量子加密；密钥交换已完成
Google	提供后量子密钥交换
AWS	KMS、ACM、Secrets Manager 已用 ML-KEM；2026 年弃用旧版 Kyber
OpenSSL 3.5+	原生支持 ML-KEM 与 X25519MLKEM768
Java（SunJSSE）	默认启用 X25519MLKEM768

尚未大规模完成的部分是后量子证书——用 ML-DSA 而非 RSA/ECDSA 签发证书。ML-DSA 的签名和公钥要大得多（数千字节 vs 约 64 字节），会撑大握手并冲击证书链的大小上限。Cloudflare 计划在 2026 年年中于源站连接上使用 ML-DSA，并在探索 Merkle 树证书以控制体积，目标是 2029 年实现完整的后量子（含身份认证）。

如何检查你是否在用后量子 TLS

在浏览器中

用 Chrome 打开任意大型网站 → 开发者工具 → **Security（安全）**标签 → 查看连接详情。后量子连接会显示类似 X25519MLKEM768 的密钥交换（旧版本上可能是 X25519Kyber768）。

用 OpenSSL 3.5+

openssl s_client -connect cloudflare.com:443 -groups X25519MLKEM768 2>/dev/null \
  | grep -i "Negotiated TLS1.3 group"
# 预期：Negotiated TLS1.3 group: X25519MLKEM768

如果报错或显示别的组，要么是你的 OpenSSL 早于 3.5，要么是服务器尚未提供后量子密钥交换。

查看你的 OpenSSL 版本

openssl version
# 需要：OpenSSL 3.5+ 才能原生支持 X25519MLKEM768

如何在你的服务器上启用

对大多数网站来说，答案就是升级，然后别去禁用它——一旦你的技术栈支持，后量子混合密钥交换就会自动启用。

Nginx / Apache

后量子密钥交换位于你的 TLS 库里，而非 Web 服务器配置中。请基于 OpenSSL 3.5+（或带 ML-KEM 的 BoringSSL）来构建或运行。链接完成后，X25519MLKEM768 会与 X25519 一起自动提供——无需新指令。不要把 ssl_ecdh_curve 锁死到单一经典曲线，否则会把混合组排除掉。

在 CDN 之后

最简单的路径：把网站放到 Cloudflare（或其他启用了 PQC 的 CDN）之后。浏览器到边缘节点的连接会立即变为后量子，源站无需改动。那 65% 的流量大多就是这样变得抗量子的——运维人员根本没碰源站服务器。

你的证书暂时不用换

后量子密钥交换不需要新证书。你现有的 RSA 或 ECC 证书照用——混合密钥交换保护的是会话，而证书目前仍使用经典签名。后量子证书（ML-DSA）是另一场更晚的迁移。

常见问题

我需要买特殊的”抗量子证书”吗？

不需要。后量子密钥交换（紧迫的那部分）完全不涉及你的证书——现有的 RSA/ECC 证书照常工作。今天任何兜售”抗量子 SSL 证书”的，基本都是营销话术；可用于生产的后量子签名（ML-DSA）尚未被公共 CA 广泛签发。

后量子 TLS 会更慢吗？

几乎不会。ML-KEM-768 计算很快——往往比 ECDHE 还快。主要成本在体积：更大的密钥份额给握手增加约 1 KB，只有在数据包上限非常小的网络上才可能多花一次往返。对绝大多数用户而言差异无法察觉。

量子计算机到底什么时候能破解 RSA？

无人知晓。可信的估计从 2030 年代初到”或许永远做不到大规模”都有。但由于先收集后解密，密钥交换的部署截止期限其实已经到了——这正是浏览器和 CDN 在 2024–2026 年间行动、而非继续等待的原因。

TLS 1.2 怎么办？

后量子混合密钥交换仅为 TLS 1.3 定义。这是启用 TLS 1.3 → 的又一个理由——它是通往抗量子 HTTPS 的唯一路径。TLS 1.2 不会获得后量子密钥交换。

ML-KEM 和 Kyber 是一回事吗？

是的——ML-KEM 是 NIST 标准化后的版本，前身叫 CRYSTALS-Kyber。旧版浏览器和工具会显示 Kyber768；标准化部署使用 ML-KEM-768。两者关系紧密但并非逐位相同，所以最终标准的客户端和标准前的服务器之间可能协商失败。到 2026 年，生态系统大体已迁移到最终的 ML-KEM。