3. TLS/SSL协议基础回顾
好，聊到Tokenization接口的TLS加密配置，我们得先回到最底层——TLS/SSL协议本身。说实话，我见过不少同学上来就配证书、调nginx，结果连握手都失败了，debug一整天发现是协议版本不对。所以这一章，我们花点时间把TLS/SSL的核心机制梳理一遍。
你可能会问：“都2025年了，SSL还有必要讲吗？”嗯，确实SSLv2/v3早就废弃了，但大家叫习惯了，其实现在说的基本都是TLS。记住一个原则：只要对外暴露接口，要么走HTTPS，要么走wss，没有例外。
3.1 什么是TLS/SSL？
说白了，TLS就是给TCP穿了一件加密外套。它工作在传输层之上、应用层之下。我以前在做一个支付网关项目时，发现流量跑在公网上就跟明信片一样——谁都能看。那之后我就彻底明白，不做加密就是裸奔。
TLS解决三个核心问题：
- 机密性——数据在传输过程中不会被偷看
- 完整性——数据不会被中途篡改
- 身份认证——你连接的确实是那个服务器，不是冒牌货
关键区分：TLS是协议，SSL是它的前身。从TLS 1.0开始，协议已经彻底革新。现在主流是TLS 1.2和TLS 1.3。如果你还在用SSL 3.0，我建议你立刻升级——那个协议早在2015年就被RFC 7568正式废弃了。
3.2 TLS握手——一次加密会话的建立过程
每次客户端和服务器建立HTTPS连接，都会先经历一次握手。这个过程我手动跟踪过很多次，说白了就是双方先打个招呼，然后商量好怎么加密，最后才开始传输真实数据。
我习惯把TLS握手分成四个阶段：
- Hello阶段——客户端说“我想连”，服务器说“好啊，我支持这些加密方式”
- 证书交换阶段——服务器亮出身份证（证书），客户端检查真伪
- 密钥协商阶段——双方用非对称加密安全地交换一个临时密钥
- 加密通信阶段——用刚才商定的对称密钥加密所有后续数据
你想想看，整个过程其实只有几次网络往返，非常高效。TLS 1.3更是把握手压缩到了1-RTT，甚至支持0-RTT，这在移动端低带宽场景下太关键了。
下面这张图展示了TLS 1.2握手的完整流程：
个人经验：我在调试一个金融接口时，客户端一直报“证书验证失败”。查了半天发现是系统时间不对——证书已经“过期”了。所以，检查客户端系统时间是我排查TLS问题的第一步。
3.3 加密套件——到底用什么算法加密？
握手过程中，客户端和服务器要协商一个加密套件。加密套件你可以理解成一份协议，指定了：用什么非对称算法交换密钥、用什么对称算法加密数据、用什么哈希算法保证完整性。
加密套件的命名格式是这样的：
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384| 组成部分 | 含义 | 常用取值 |
|---|---|---|
| TLS | 协议前缀 | TLS / SSL |
| ECDHE | 密钥交换算法 | ECDHE（首选）、RSA、DHE |
| RSA | 证书签名认证算法 | RSA、ECDSA |
| AES_256_GCM | 对称加密算法 + 模式 | AES_128_GCM、CHACHA20_POLY1305 |
| SHA384 | 伪随机函数（PRF） | SHA256、SHA384 |
注意，密钥交换算法是关键。我建议优先选择基于ECDHE的套件，因为它支持前向安全性（PFS）。什么意思呢？就算你将来私钥泄露了，以前所有的加密通信记录依然安全。我在设计Tokenization接口时就强制只允许ECDHE套件。
避坑指南：千万别用RSA密钥交换！不支持前向安全性。我曾经接手过一个遗留系统，用的就是TLS_RSA_WITH_AES_128_CBC_SHA。三个月后服务器私钥泄露，所有历史通信数据全部可解密，那个教训太深刻了。
3.4 数字证书——服务器的身份证
证书的作用我上面提了，就是证明“你是你”。一个合法的X.509证书包含：
- 服务器域名（CN / SAN）
- 证书签发机构（CA）签名
- 公钥（用在密钥交换中）
- 有效期（开始时间 ~ 结束时间）
- 指纹（用于验证证书完整性）
证书验证的链条是这样的：
- 客户端收到服务器证书
- 检查证书有效期
- 检查证书是否被吊销（CRL / OCSP）
- 用CA的公钥验证证书签名
- 验证域名是否匹配
- 全部通过 → 继续握手；失败 → 直接断开
重要提示：自签名证书不是不能用，但在生产环境不能对公网使用。内部测试或开发环境可以临时用一下，但一定记得在客户端手动信任该自签名根证书。我见过有人在生产环境用自签证书，结果被安全审计直接通报批评。
3.5 当前协议版本实战选择
最后，给出一份实际可用的配置清单。现在是2025年，我建议直接套用：
| 属性 | 推荐值 | 说明 |
|---|---|---|
| TLS版本 | TLS 1.2 / 1.3 | TLS 1.3性能更好，但兼容性需评估 |
| 禁用版本 | SSL 2.0/3.0, TLS 1.0/1.1 | 全部有已知漏洞，必须禁用 |
| 密钥交换 | ECDHE (P-256 / X25519) | 支持前向安全性，性能也扎实 |
| 对称加密 | AES-256-GCM / CHACHA20-Poly1305 | 两种都是AEAD模式，不推荐CBC |
| 证书类型 | RSA 2048+ 或 ECDSA P-256 | 前者兼容性好，后者性能好 |