【ZeroRange WebRTC】TLS 底层原理与工作机制（深入解析）
TLS 底层原理与工作机制（深入解析）
本文系统讲解 TLS 的握手、密钥协商、证书校验、密钥派生、记录层加密（AEAD）、重放防护与版本差异（TLS 1.2/1.3），并结合 SVG 图示帮助理解。内容以实践为导向，适合配合 KVS WebRTC 示例日志定位与验证。
说明：TLS（Transport Layer Security，传输层安全协议）是 HTTPS 与 WSS 所依赖的加密与认证基础。HTTPS 即“HTTP over TLS”，WSS 即“WebSocket over TLS”。二者在建立连接后，应用层数据都通过同一个 TLS 信道加密与校验。
目录
- 概览：TLS 的目标与边界
- 握手流程（TLS 1.3）与核心机制
- 证书链校验与主机名匹配（SNI）
- 密钥派生（HKDF）与流量密钥
- 记录层加密：AEAD（AES‑GCM/CHACHA20‑POLY1305）
- 序列号、Nonce 与防重放
- TLS 1.3 vs 1.2 的关键差异
- 实践要点与常见故障定位
- 附：图示（握手、记录层、密钥派生、版本对比）
概览：TLS 的目标与边界
- 目标：
- 保密性：抵御窃听，确保数据仅被通信双方读取。
- 完整性：防篡改，任何比特级修改都会在校验时被发现。
- 真实性：确认服务端真实身份（可选客户端身份）。
- 边界：
- TLS 保护“传输层”；它不做应用层的身份授权与审计（这由 SigV4 等机制提供）。
握手流程（TLS 1.3）与核心机制
- ClientHello：
- 提供支持的密码套件、曲线、版本与扩展（SNI/ALPN）。
- 发送 ECDHE 的 KeyShare（如 P‑256/X25519），用于前向保密。
- ServerHello：
- 选择版本与套件，返回服务端 KeyShare。
- 后续握手消息（证书链、签名）在加密通道中发送（1.3 的握手阶段分层更简化）。
- 证书链与签名：
- 服务端发送证书链，客户端用受信任根 CA 验证签发与主机名匹配（SNI 对应）。
- 服务端对握手内容做签名，证明握手信息来自证书主体。
- 证书链组成：叶子证书（站点证书）→ 中间 CA → 根 CA。客户端需持有受信任根 CA（系统或配置路径），并验证链的有效期、签名与撤销（CRL/OCSP）状态。
- 主机名校验：证书的 SAN（Subject Alternative Name）或 CN（Common Name）必须覆盖 SNI 指定的主机名；不匹配则握手失败，防止中间人攻击。
- TLS 1.3 的握手证明：
- Certificate：服务端发送证书链；
- CertificateVerify：服务端用证书私钥对“握手抄本”（Transcript）做数字签名，证明其对证书私钥的持有；
- Finished：双方用握手密钥派生出的 finished_key 对“握手抄本”做 MAC，验证密钥协商与握手内容未被篡改（客户端和服务端各发送一次）。
- 加密阶段：在 TLS 1.3 中，自 ServerHello 之后的握手消息（含证书链与签名）均在加密通道内发送，降低被动监听下的信息泄露。
- 完成密钥协商：
- 双方用 ECDHE 计算共享密钥，经过 HKDF 派生出握手密钥与应用流量密钥。
- 前向保密（PFS）：ECDHE 使用临时密钥对（Ephemeral Keys），即便长期私钥泄露，也无法解密过去的会话数据。
- 密钥日程（Key Schedule）：
- HKDF‑Extract → early_secret / handshake_secret / master_secret；
- 从 handshake_secret 派生握手阶段的读/写方向密钥；
- 从 master_secret 派生应用阶段的 Client/Server Traffic Secret（读/写分离），进一步派生记录层 Key/IV/Nonce 基础盐；
- 可通过 KeyUpdate 触发重钥（re‑key），提升长连接下的安全性。
- 应用数据保护开始：双方发送 Finished 成功后，改用应用流量密钥保护后续的 HTTP 报文或 WebSocket 帧（即 HTTPS/WSS 的上层数据）。
证书链校验与主机名匹配（SNI）
- 根 CA 与链验证：
- 客户端加载受信任根 CA（系统或配置文件），验证证书链完整性与有效期。
- 主机名匹配：
- SNI 在握手中声明目标主机名；证书的 CN/SAN 必须覆盖该主机名。
- 失败后果：
- 校验失败/主机名不匹配会导致握手终止，后续 HTTPS/WSS 无法建立。
密钥派生（HKDF）与流量密钥
- 共享密钥 → HKDF：
- 输入：ECDHE 生成的共享密钥 + 握手上下文（含随机数/扩展等）。
- 输出：握手密钥与应用流量密钥（读/写方向分离）。
- 前向保密：
- 即便长期密钥泄露，缺乏会话握手材料也无法还原过去会话。
记录层加密：AEAD（AES‑GCM/CHACHA20‑POLY1305）
- AEAD 算法：
- 加密同时生成认证标签（Tag），接收端验证 Tag 确保完整性。
- Nonce 与序列号：
- 每个记录都有唯一 Nonce（由固定盐 + 递增序列号派生），避免重用。
- 完整性与防篡改：
- 解密前先校验认证标签；任何改动会导致校验失败并丢弃。
序列号、Nonce 与防重放
- 序列号：
- 记录层维护递增序列号，作为 Nonce 的派生因子和重放检测基础。
- 防重放：
- AEAD 与序列号机制结合，确保同密钥下每条记录唯一；应用层还可再叠加时间窗口与请求签名（如 SigV4）。
TLS 1.3 vs 1.2 的关键差异
- 1.3：
- 仅支持具前向保密的 ECDHE；统一采用 AEAD；简化握手与密钥派生（HKDF），时延更低、抗攻击更强。
- 1.2：
- 可用 ECDHE 或旧式 RSA 密钥交换；记录层可用 AEAD 或“流量密钥 + HMAC”的非 AEAD；需谨慎选择套件避免弱配置。
实践要点与常见故障定位
- CA 与主机名：确保根 CA 可用、主机名与证书匹配（SNI），否则握手失败。
- 版本与套件：优先 TLS 1.3（AES‑GCM/CHACHA20‑POLY1305）；禁用已知弱套件与旧版本。
- 日志对照：
- 握手成功会看到
TLSv1.3与套件日志（例如TLS_AES_256_GCM_SHA384）。 - ALPN 显示
h2/http/1.1协商结果；失败场景下查看证书加载与主机名校验日志。
- 握手成功会看到
- 与应用层鉴权协同：SigV4 提供请求级身份与时间/重放控制，TLS 负责传输层保密与完整性，两者互补。