TLS协议基础：握手、加密套件、证书验证与TLS 1.3新特性
上一章我们聊了Tokenization的底层原理，这一章必须把TLS讲透。为什么？我敢说90%的Tokenization泄露事故，根子都在TLS配置上。你想想看，令牌在传输过程中如果被截获，等于把保险柜钥匙直接给了小偷。
做个比喻：TLS就是网络世界里的防弹运钞车。车不够结实，押运员再专业也白搭。我自己做过一次安全评估，客户自建了Tokenization平台，结果TLS证书居然过期两个月了都没发现……嗯，后面的事你懂的。
咱们先把TLS的核心骨架说清楚。我从四个维度展开：握手流程、加密套件选择、证书验证机制、以及TLS 1.3带来的变化。
3.1 TLS握手：究竟在握什么？
很多刚入行的朋友觉得TLS握手就是交换个密钥。其实没那么简单。我习惯把握手分成三步来看：
- 密码参数协商——客户端和服务端互相报家底，选出双方都支持的最强加密套件。
- 身份认证——服务端（通常）出示证书，客户端验证你是不是你声称的那个人。
- 会话密钥协商——用DH或ECDH交换密钥材料，生成最终加密密钥。
在TLS 1.2及之前，这个流程需要2-RTT（两次往返）。客户发ClientHello，服务端回ServerHello+证书，客户端再发密钥交换参数……一来一回，时间就在等待中溜走了。
划重点：握手阶段的任何失败都意味着后续数据交换不安全。我在渗透测试中遇到过一种情况：服务端配置了不完整的证书链，导致客户端证书验证失败，但某些老旧客户端直接降级为无认证的匿名套件……这问题非常隐蔽。
3.2 加密套件：选错就是万丈深渊
加密套件（Cipher Suite）是TLS的核心配置。它定义了4件事：
- 密钥交换算法（如ECDHE、DHE、RSA）
- 身份认证算法（如RSA、ECDSA）
- 对称加密算法与模式（如AES-256-GCM、CHACHA20-POLY1305）
- 消息认证码（如HMAC-SHA384）
常见的套件命名示例：TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
翻译成人话就是：用椭圆曲线DH交换密钥、RSA签名验证身份、AES-256-GCM加密数据、SHA384做完整性校验。
避雷指南：我曾经在金融客户那里见到他们还开着 TLS_RSA_WITH_3DES_EDE_CBC_SHA 这个套件。3DES已经是17年NIST宣布淘汰的算法，CBC模式又容易受Padding Oracle攻击。你想想看，Tokenization的令牌如果用这种套件保护，跟明传有什么区别？
我建议你现在就对照这张表检查你的服务端配置：
| 加密套件 | 安全等级 | 推荐场景 |
|---|---|---|
| TLS_AES_256_GCM_SHA384 (TLS 1.3) | ✅ 强 | Tokenization首选 |
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | ✅ 强 | TLS 1.2兼容场景 |
| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 | ✅ 强 | 移动端/ARM优化 |
| TLS_RSA_WITH_AES_256_CBC_SHA256 | ⚠️ 弱 | 不推荐，无前向安全 |
| TLS_RSA_WITH_3DES_EDE_CBC_SHA | ❌ 已弃用 | 禁止 |
小提示：你可以用 openssl ciphers -v 'HIGH:!aNULL:!eNULL:!LOW:!MEDIUM' 来快速列出当前系统的安全套件。我每个季度都会跑一次这个命令，再配合扫描工具。
3.3 证书验证：信任链上最薄弱的环节
证书验证的核心是链式信任。一个有效的X.509证书链包括：
- 根CA证书——自签名，预埋在操作系统或浏览器中。
- 中间CA证书——由根CA签发，用于层级隔离。
- 服务器证书——由中间CA签发，绑定域名和公钥。
验证过程不仅仅是检查签名。还需要验证：
- 证书是否在有效期内
- 域名是否匹配（SNI）
- 证书是否被吊销（CRL或OCSP）
- 密钥用法是否包含“数字签名”和“密钥加密”
致命陷阱：我扫描过某Tokenization网关，它竟然使用了自签名证书，并且客户端代码里关闭了证书验证。这意味着中间人可以轻松插入假证书，所有令牌流量一览无余。更夸张的是，他们还在代码里写死了 verify=False ……这相当于给运钞车安了透明的玻璃门。
对于Tokenization系统，我强烈要求你做两件事：
- 使用OCSP Stapling，避免客户端每次连接都去查询CA的吊销列表（增加延迟且可能泄露隐私）。
- 证书至少使用RSA 2048位或ECDSA P-256，不要用1024位。
3.4 TLS 1.3新特性：从1.2到1.3的变化
TLS 1.3（RFC 8446）是一次彻底的洗牌。它去掉了所有不安全的特性，同时也打破了向下兼容的美梦。我挑几个对Tokenization安全评估影响最大的点：
- 握手缩短到1-RTT——0-RTT模式甚至可以做到“上一轮握完，下一轮直接发加密数据”。但0-RTT存在重放风险，Tokenization场景下慎用。
- 移除静态RSA和DH——所有密钥交换必须使用ECDHE或DHE，强制提供前向安全性。
- 压缩功能移除——CRIME攻击无法再复现。
- 加密套件数量精简——只保留了5个套件，且全部使用AEAD认证加密（GCM或Poly1305）。
- 握手消息加密——证书也开始加密传输，防止中间人探测服务器证书细节。
关键结论：如果Tokenization系统已经支持TLS 1.3，尽量关闭1.2和1.1。虽然有一小部分老旧客户端无法兼容，但令牌泄露的风险远大于那一点点兼容性损失。我见过一个客户，为了兼容一台2012年的工控机，硬撑着开着TLS 1.0，结果被POODLE攻击打穿了。
最后说一句心里话：TLS这个领域，细节决定生死。配置一个“看起来能用”的TLS很简单，但要配置一个“真正安全”的TLS却需要理解上述每一个环节。后面几章我们会把这些知识和Tokenization的特定威胁结合起来做实战评估。嗯，先消化这些基础吧。