后量子 TLS：ML-KEM 混合密钥交换与 Merkle 树证书

今天生产环境里的“后量子 TLS”指的就是一件事：混合密钥交换 X25519MLKEM768。Chrome、Edge 等客户端遇到支持它的服务器时已经默认使用。它保护的是流量的机密性，防的是“现在录下、将来用量子计算机解密”。证书和签名仍是传统算法，因为后量子签名太大；Web 对此的方案是 Merkle 树证书，截至 2026 年 11 月仍处于实验阶段。

为什么先改密钥交换

密钥交换最紧迫，原因是“先存后解”（harvest now, decrypt later）：今天录下的流量，等到能破解密码的量子计算机出现后就可以解密。Shor 算法能同时攻破 RSA 和椭圆曲线密码，2026 年一次 TLS 会话的 ECDHE 密钥一旦被算出，它加密的所有内容都会暴露。

签名不一样。伪造签名只在证书有效、攻击者实时在线时才有用，未来造出的量子计算机没法回过头去冒充过去某次连接里的服务器。

国密 SM2 同样基于椭圆曲线，面临同样的量子威胁。国内也已启动新一代商用密码算法（包括抗量子算法）的研究和征集，但截至 2026 年 11 月还没有进入 TLS 实际部署。

标准：ML-KEM、ML-DSA 与 SLH-DSA

NIST 在 2024 年 8 月 13 日发布了首批三项后量子标准，它们在 TLS 里分工不同。

TLS 1.3 密钥交换方面，RFC 10024（2026 年 8 月）定义了三个混合组：X25519MLKEM768（0x11EC）、SecP256r1MLKEM768 和 SecP384r1MLKEM1024。更早的部署用的是 X25519Kyber768Draft00（0x6399），那是 Kyber 标准化之前的版本，浏览器已经不再支持。

混合密钥交换怎么工作

X25519MLKEM768 在同一个 TLS 1.3 密钥份额里并排运行 ML-KEM-768 和 X25519，再把两个结果拼起来。握手消息流程不变，变的只是 key_share 的大小。

ClientHello
  supported_groups: X25519MLKEM768, X25519, ...
  key_share (X25519MLKEM768) = ML-KEM-768 封装公钥 (1184 B) || X25519 公钥 (32 B)
                               = 1216 字节
                                   |
                                   v
ServerHello
  key_share (X25519MLKEM768) = ML-KEM-768 密文 (1088 B) || X25519 公钥 (32 B)
                               = 1120 字节

共享密钥 = ML-KEM 共享密钥 (32 B) || X25519 共享密钥 (32 B) = 64 字节
           -> TLS 1.3 HKDF 密钥派生（不变）

攻击者必须两个都攻破才能拿到会话密钥。ML-KEM 万一有缺陷，连接也不比传统 X25519 弱；量子计算机攻破 X25519，ML-KEM 依然有效。

代价是字节数。用 OpenSSL 3.6.1 对本地测试服务器实测：

计算本身很便宜，ML-KEM 在普通 CPU 上很快，麻烦出在体积上。

截至 2026 年 11 月的支持情况

浏览器和新版服务器之间，混合 ML-KEM 已经是默认行为。

Chrome 131 一次只提供一个后量子密钥份额。Google 的解释是同时发送 Kyber 和 ML-KEM 会让 ClientHello 过大，所以只支持旧 Kyber 码点的服务器，和新版 Chrome 之间只能协商出传统 X25519。

服务器端通常只需要新版 TLS 库。nginx 链接 OpenSSL 3.5 或更新版本时，可以显式指定顺序：

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1:secp384r1;

先用 nginx -V 看清链接的 OpenSSL 版本。很多发行版和宝塔默认安装的 nginx 链接的是 OpenSSL 3.0、3.2 或更早版本，它们不认识 X25519MLKEM768 这个名字，加上这一行 nginx 会启动失败。

命令行测试（OpenSSL 3.5+）：

openssl s_client -connect example.com:443 -servername example.com \
  -groups X25519MLKEM768 -brief </dev/null

Connecting to 203.0.113.10
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=example.com
Signature type: ecdsa_secp256r1_sha256
Verification: OK
Negotiated TLS1.3 group: X25519MLKEM768

不支持的服务器会返回 alert handshake failure（编号 40），因为客户端没有提供别的组。注意 Signature type: ecdsa_secp256r1_sha256 这一行：密钥交换是后量子的，身份认证还不是。更多组和协议测试命令见加密套件与协议命令。

ClientHello 变大与中间设备

部署中最常见的问题不在密码学，而在处理不了“一个包装不下的 ClientHello”的网络设备。带 X25519MLKEM768 份额的 ClientHello 视其他扩展而定约 1.5 KB 到 1.8 KB，在常见的 1500 字节 MTU 下装不进一个 TCP 段或 QUIC 包。

已知的故障模式：

• 防火墙、TLS 解密代理、负载均衡只读第一个 TCP 段来提取 SNI，读不全就丢包或重置连接。
• 老设备为 ClientHello 分配了固定大小的缓冲区，消息超长就直接断开。
• 不认识新组的服务器只能回 HelloRetryRequest；行为规范的客户端会同时附带一个 X25519 份额来避免这多出的一次往返。

Chrome 启用混合密钥交换时，给企业管理员提供了 PostQuantumKeyAgreementEnabled 策略作为临时开关，等设备厂商修复。根本办法是升级中间设备；在源站启用 ML-KEM 组之前，先确认负载均衡、WAF 固件是新的。企业内网如果部署了上网行为管理或 TLS 解密设备，尤其要先测。

后量子证书为什么难

后量子签名比 ECDSA 大一个数量级，而一次 TLS 握手要带好几个签名。FIPS 204 及常见算法的尺寸：

一次典型的网站握手至少携带两个公钥（叶子证书和中间证书）和五个签名：中间 CA 对叶子证书的签名、根 CA 对中间证书的签名、服务器的 CertificateVerify，以及证书透明度要求的两个或更多 SCT。如果全部换成 ML-DSA-44，认证数据约为 5 × 2,420 + 2 × 1,312 ≈ 14.7 KB，而 ECDSA 证书链不到 1 KB。用 OpenSSL 3.6.1 在本地生成最简单的自签名证书也能看到这个跳变：P-256 为 389 字节，RSA-2048 为 785 字节，ML-DSA-44 为 3,985 字节。

14 KB 的问题在于，它会让服务器第一轮发送的数据超出 TCP 初始拥塞窗口（RFC 6928 规定的 10 个报文段），每个新连接都要多几次往返，还会加剧上一节的中间设备问题。Google 2026 年 2 月的公告明确说，Chrome 近期没有把带后量子算法的 X.509 证书加入 Chrome 根证书库的计划。

Merkle 树证书

Merkle 树证书（Merkle Tree Certificates，MTC）用“证书包含在某棵已签名 Merkle 树中”的简短证明，取代一串签名。设计来自 IETF 的 PLANTS（PKI, Logs, And Tree Signatures）工作组，草案名为 draft-ietf-plants-merkle-tree-certs，由 David Benjamin 早先的个人草案发展而来。

传统 X.509 + CT                              Merkle 树证书
---------------                              -------------
根 CA 签中间证书       （签名）              CA 对覆盖大量证书的树头签一次名
中间 CA 签叶子证书     （签名）              （1 个签名，浏览器提前另行获取）
CT 日志签 SCT          （2 个以上签名）
服务器签握手           （签名）
                                             服务器发送：公钥 + 包含证明（几个哈希）
服务器发送：证书链 + SCT + CertificateVerify    + CertificateVerify

浏览器事先拿到已签名的树头，握手里传的就只是哈希而不是大签名；而且透明度是天然的，证书不可能脱离公开的树而存在。Google 在 2026 年 2 月公布了分阶段计划：先与 Cloudflare 在真实流量上做可行性研究，期间每个 MTC 连接都有一张普通 X.509 证书兜底；然后邀请现有 CT 日志运营方启动公共 MTC；再建立只接受 MTC 的独立“Chrome 抗量子根证书库”。截至 2026 年 11 月这仍是实验，草案也还在变化。

防降级：认证迁移的真正难点

只增加后量子证书，在浏览器能拒绝传统证书之前保护不了任何人。拥有量子计算机的攻击者可以用任意一家受信 CA 的传统密钥伪造证书冒充网站，不管真网站用的是哪种证书。所以 Chromium 2026 年 2 月发布的后量子认证路线图分了几个阶段：先加入后量子选项；再让单个网站通过类似 HSTS 的机制选择“必须后量子”；然后要求整个 PKI 都是后量子的；最后在很远的将来要求所有服务器密钥都是后量子的。其中“网站自愿选择”的思路和 HSTS 一样，是一个带 max-age、由浏览器记住的响应头。

现在该做什么

大多数网站现在只需开启 X25519MLKEM768，暂时不要购买“后量子证书”。完整清单：

1. 开启混合密钥交换。 升级到支持 X25519MLKEM768 的 TLS 库（OpenSSL 3.5+、基于新版 BoringSSL 的代理，或支持它的 CDN），用 s_client -groups 确认。
2. 检查网络路径。 经过负载均衡、WAF 和 TLS 解密设备完整测一遍，大 ClientHello 最容易在这些地方出问题。
3. 保持 TLS 1.3 开启。 混合组只为 TLS 1.3 定义，参见 TLS 1.3。
4. 盘点长期机密。 VPN、内部 API、专线上需要保密十年以上的数据，应最先要求 ML-KEM。
5. 公网网站先别买“后量子证书”。 把证书签发自动化，将来切换到 MTC 或 ML-DSA 时就只是改配置，而不是一个项目。

术语见后量子密码、ML-KEM 和 X25519MLKEM768。