后量子 TLS 已经进了你的握手，但它只解决了一半

先说结论：密钥交换这一半，基本已经解决了；签名那一半没有。

威胁模型不是“量子计算机要来了”

真正的威胁叫 harvest now, decrypt later：今天有人把你站上的 TLS 流量整段录下来存着，等哪天量子计算机能用了再回头解。

它的可怕之处在于不需要现在就成功。一个今天录下的会话，如果内容需要保密十年，那么十年内量子计算到位，这次录制就赚了。

所以这不是“等量子计算机出现再说”的事。判据是：你要保护的信息，保密期有多长。 医疗记录、身份材料、长期密钥 —— 这些的保密期都是几十年，现在就该管。

NIST 2024 年定稿了三个标准

• FIPS 203 — ML-KEM：密钥封装，用来替换 ECDH 这类密钥交换
• FIPS 204 — ML-DSA：数字签名
• FIPS 205 — SLH-DSA：另一族签名，基于哈希，签名更大但假设更保守

浏览器和 CDN 的做法：混合

现在主流浏览器与 CDN 默认协商的是 X25519MLKEM768 这类混合组 —— 经典椭圆曲线和后量子 KEM 同时做一遍，两边的输出拼起来当密钥材料。

混合是刻意的，不是过渡期的偷懒：

• 后量子算法被分析的时间短得多，谁也不敢保证十年后没有新的攻击
• 经典算法就算将来被量子计算机破掉，今天也仍然是安全的
• 两个一起做，任意一个没破，会话就没破

代价是一次握手多算一遍 KEM。相对于它挡住的东西，这个代价可以忽略。

为什么说“只解决了一半”

密钥交换是协商一个临时密钥。它的改动完全局限在握手内部：客户端和服务端各算一次，对上层完全透明。所以浏览器和 CDN 升级一下，你就白拿了。

签名不一样。 证书链上每一环的签名都要换成后量子算法，而后量子签名和公钥的体积大得多 —— 签名动辄 2 KB 以上，公钥也是千字节级。这带来两个连锁问题：

1. 证书链变胖。一个三层链，光签名和公钥就能多出好几 KB。
2. 握手可能超过单个 TLS 记录的容量，触发分片，或者撞上某些中间设备的缓冲区上限。

第二点是运维里最阴的那种问题：平时没事，某天换了个 CA 或加了一层中间证书，突然就有人连不上。

站主现在该做什么

• 走 CDN / 云厂商的话，密钥交换那一半你已经白拿了，不需要做任何事
• 要开始留意的是证书链长度。能上 TLS 1.3、能省掉中间证书就省
• 自己跑 TLS 终结的话，先去确认你用的库和版本已经支持 ML-KEM 混合组，然后打开它
• 不要现在就为了后量子去改签名算法 —— 生态（CA、OCSP、客户端校验）还没准备好

我自己的判断是：这一轮不用急着动，但要把“证书链长度”记进巡检清单。它是“看起来完全没事、某天突然握手失败”的典型，而这类问题的排查成本远高于预防成本。