📚 课程目录第1章后量子TLS实验环境概述

1. 后量子TLS实验环境概述

后量子密码学（Post-Quantum Cryptography，PQC）迁移并不是简单地“把 RSA 换成某个新算法”，而是一次贯穿密钥交换、身份认证、证书体系、协议协商与运维监控的系统性演进。NIST 在 2024 年正式发布 FIPS 203（ML-KEM）、FIPS 204（ML-DSA）与 FIPS 205（SLH-DSA）三项标准后，工业界的关注点迅速从“算法是否安全”转向“如何在实际协议栈中落地”。TLS 1.3 作为当前互联网加密流量的主力协议，自然成为 PQC 迁移的第一战场。本节先建立整体认知：为什么要迁移、TLS 1.3 协议栈中哪些环节会受影响、实验环境应当如何组织与选型。

一、迁移背景：为什么现在就要动手

威胁模型的核心是“先存储、后解密”（Harvest Now, Decrypt Later）。攻击者今天抓取并保存的 TLS 会话密文，可能在量子计算机成熟后被回溯解密。这意味着对于需要长期保密的数据（身份信息、医疗记录、政务数据、长期密钥），迁移的紧迫性取决于“数据保密期限 + 迁移周期”是否超过量子威胁到来的时间窗口。工程上普遍认为迁移周期以年计，因此现在开始搭建实验环境、验证互操作性，是合理且必要的。

迁移的难点集中在三处：其一，密钥交换需要引入 ML-KEM 等 KEM 算法，并处理其较大的公钥与密文尺寸；其二，身份认证需要引入 ML-DSA 等签名算法，牵动证书链、CA 体系与信任存储；其三，协议协商需要在不破坏现有客户端兼容性的前提下，通过混合模式（Hybrid）平滑过渡。实验环境的价值，正是在可控范围内把这三处难点逐一暴露、测量和验证。

二、TLS 1.3 协议栈回顾：迁移的着力点

TLS 1.3 的握手可概括为：ClientHello / ServerHello 协商参数与密钥交换组，随后双方通过 HKDF 派生握手密钥，服务器发送 Certificate 与 CertificateVerify 完成身份认证，最后 Finished 校验握手完整性，应用数据在 AEAD 保护下传输。与 PQC 相关的着力点如下：

supported_groups / key_share 扩展：决定密钥交换算法。PQC 迁移通常新增 X25519MLKEM768 这类混合组，客户端在 key_share 中携带混合公钥。
signature_algorithms 扩展：决定证书签名与 CertificateVerify 所用算法，需要加入 ML-DSA 等新签名方案。
Certificate 消息：PQC 证书与公钥尺寸显著增大，可能触发握手分片与 TCP 分段，影响握手时延。
密钥派生：混合模式下，共享密钥由经典 ECDH 结果与 KEM 共享秘密拼接后再进入 HKDF，需确认拼接顺序与标签一致。

需要特别强调：TLS 1.3 的握手密钥派生依赖 HKDF-Extract/Expand，混合密钥交换的共享秘密如何拼接、以什么标签进入 HKDF，必须由实现严格遵循草案规范，否则会出现“双方都认为握手成功但密钥不一致”的隐蔽故障。这是实验环境要重点验证的内容。

三、实验环境总体架构

一个可用的后量子 TLS 实验环境，最小闭环应包含四类角色：PQC 使能的客户端、PQC 使能的服务端、实验 CA 与观测工具。客户端与服务端建议选用已合入 PQC 支持的 OpenSSL 3.5 或 BoringSSL 分支，服务端可挂在 nginx 或自研 TLS 终止程序之后；实验 CA 用 OpenSSL 命令行签发 ML-DSA 证书或混合证书链；观测工具至少包括 tshark 抓包与 qlog 事件日志，用于核对 supported_groups、key_share 长度、Certificate 消息分片情况与握手总字节数。

部署形态上推荐容器化：用 docker compose 编排 client、server、ca 三个容器，共享一个实验网络，证书通过挂载卷注入。这样每次实验从干净状态开始，避免“上次实验残留的信任存储”污染结果。一个典型的目录组织如下：

pqc-tls-lab/
├── ca/            # 实验 CA 私钥、证书、签发脚本
├── server/        # nginx 配置、ML-DSA 证书、私钥
├── client/        # 客户端测试脚本、信任存储
├── capture/       # pcap 与 qlog 输出目录
└── compose.yaml   # 三容器编排

四、组件选型原则

选型不应追求“功能最多”，而应围绕实验目标设定四条准则。第一，标准符合性优先：算法实现须对应 FIPS 203/204/205，混合密钥交换须遵循 IETF 草案中定义的组标识与共享秘密拼接方式，否则测出的互操作性结论没有参考价值。第二，可观测性：所选实现要能输出握手细节，至少能拿到协商结果、密钥交换组、证书链长度与握手耗时，否则无法定位“握手失败发生在哪一步”。第三，可替换性：算法与协议参数应可配置切换，便于在同一环境中对比纯经典、纯 PQC 与混合三种模式。第四，可复现性：固定镜像版本与配置，用脚本完成证书签发与环境启动，保证他人能复现同一组结果。

建议第一轮实验只验证“能否握手成功 + 协商结果是否符合预期”，第二轮再引入时延与字节数测量。先保证正确性，再谈性能，可以避免把配置错误误判为算法性能问题。

五、第一轮实验的观察点

环境搭好后，第一件事不是压测，而是确认握手链路真的走了 PQC 路径。可用如下命令发起一次连接并观察协商细节（示例参数，实际以所用版本输出为准）：

openssl s_client -connect server:4433 \
  -groups X25519MLKEM768 \
  -CAfile ca/pqc-root.crt \
  -tls1_3 -brief

判断依据有三条：其一，输出中协商组应为 X25519MLKEM768，而非 X25519；其二，Certificate 链中签名算法应为 ML-DSA 系列，且验证通过；其三，抓包中 ClientHello 的 key_share 长度明显大于纯 X25519 情形，Certificate 消息可能被分片。若握手失败，优先检查信任存储是否包含实验根证书、服务端是否加载了对应私钥、以及双方对混合组标识的理解是否一致。这三类问题覆盖了实验初期绝大多数故障。

完成上述验证后，实验环境即具备继续深入的基础：后续可在此基础上对比不同混合组的握手时延、测量 PQC 证书链对首字节时间的影响、验证降级攻击防护，以及模拟部分客户端不支持 PQC 时的回退行为。