TLS基础回顾：握手协议、加密算法与证书体系
做TLS版本升级，最怕什么？
怕对基础理解不透，日志都看不懂。
我之前带团队排查过一起"诡异断连"问题——客户端和服务端握手要8秒，查了半天才发现是证书链没传完整。从那以后，我每次讲TLS都必须先拉一遍这三块：握手怎么握、密码怎么算、证书怎么验。
2.1 握手协议——安全通道的"敲门砖"
握手，说白了就是双方先对暗号。暗号对上了，才开启加密通信。
我习惯把握手分成两个阶段：
- 第一阶段（明文交换）：ClientHello + ServerHello + 证书。这时候还没加密，但决定了后面用什么算法。
- 第二阶段（密钥协商）：用非对称加密交换一个"预主密钥"，然后双方各自推导出会话密钥。
你想想看，如果中间人能在第一阶段篡改"支持的算法列表"，强制降级到RC4这种弱密码——嗯，这就是经典的降级攻击。TLS 1.3直接砍掉了很多历史包袱，握手从2-RTT降到1-RTT。
TLS 1.2 vs TLS 1.3 握手对比
| 对比项 | TLS 1.2 | TLS 1.3 |
|---|---|---|
| 往返次数 | 2-RTT（完整握手） | 1-RTT |
| 密钥交换算法 | RSA / DHE / ECDHE | 仅 (EC)DHE |
| 协商阶段 | 先定密码套件，再密钥交换 | 密钥交换与算法协商合并 |
| 0-RTT 恢复 | 不支持（Session Ticket 非标准） | 原生支持 PSK + 0-RTT |
实际升级的时候，我最烦的就是 1.3 的 0-RTT——它把首次连接的请求也加密了，如果审计日志要记录请求首行，你得用导出的 key log 才能解密。我曾经因为没提前安排 key log 的保存策略，导致出问题后整整查了两天日志才定位到根因。
2.2 加密算法——三条腿的凳子
TLS能安全，靠的是三类算法协同工作：
- 非对称加密（如RSA、ECDHE）——用来交换密钥。速度慢，但安全。
- 对称加密（如AES-128-GCM）——用来真正加密数据。速度快，但要先约好密钥。
- 哈希算法（如SHA-256、SHA-384）——用来做完整性校验和消息认证码。
我打个比方：非对称是保险柜钥匙的快递盒，对称是保险柜本身，哈希是封箱胶带上的防伪标记。任何一个缺了，通道都不牢靠。
我在项目里常用 AES-256-GCM 搭配 ECDHE 做密钥交换。前者硬件加速支持好，后者提供前向安全性——即使私钥泄露，历史会话也无法被解密。这一点在审计合规里特别重要，PCI DSS 4.0 就明确要求使用前向安全的密码套件。
2.3 证书体系——谁来证明你是你
握手时，服务端会发来一张证书。客户端怎么知道这张证书是真的？
靠的是一棵"信任树"——PKI 体系，根 CA 自己签自己（自签名），中间 CA 由根签，终端证书由中间 CA 签。客户端本地预装了根证书，一路验证签名链，如果链上某环证书过期、被吊销、域名不匹配——握手直接失败。
我之前遇到过一件事：某银行内部系统升级 TLS 1.3 后，旧应用突然连不上。查了半天，发现是旧应用没有打包中间CA证书，只发了终端证书。TLS 1.2 下很多客户端会自动补全，但 1.3 的验证更严格，直接拒了。嗯，那以后我养成了个习惯——上线前一定用 OpenSSL 手动验证证书链完整性。
避坑指南：升级 TLS 版本时，别忘了同步检查证书吊销机制（CRL/OCSP）。很多环境之前用 CRL 分发，升级后 OCSP stapling 不工作了，因为负载均衡器配置没更新。我曾经吃过一次亏，线上出现大量 OCSP 请求超时，导致握手延迟飙到10秒以上。
2.4 小结一下这个基础
升级TLS版本，说穿了就是换一套更硬的"握手+加密+证书"组合。
- 握手协议决定了交互效率和可协商的算法集——1.3砍掉了不安全选项。
- 加密算法决定了通信的保密性和完整性——别再用旧算法了。
- 证书体系决定了信任链——注意中间CA缺失、吊销失效。
这些基础搞扎实了，后面看审计日志才不至于一头雾水。你想想看，当日志里出现"unknown_ca"或者"handshake_failure"时，如果连证书链结构都不清楚，那排查根本无从下手。我个人是强烈建议团队在升级前先做一次 OpenSSL 全链路握手测试，每条日志都看一遍，确认三步都走通。