4. TLS/SSL协议概述：历史版本、TLS vs SSL、TLS在现代网络中的地位
说到网络加密，TLS/SSL 是个绕不开的话题。不管你是做 Web 开发、写 API 网关，还是搞数据令牌化传输，最终都避不开这一层。我最早接触 SSL 是在 2010 年左右，帮一个电商平台配支付网关，那时候 TLS 1.2 刚发布不久，大部分服务器还在跑 TLS 1.0。说实话，当时我对这些版本号背后的差异也没深究，直到后来线上出了几次兼容性问题，才老老实实把协议演进史补了一遍。
这一章我就用自己的理解，把 TLS/SSL 的来龙去脉、版本差异、以及它今天在网络里的定位，给你捋清楚。
4.1 SSL的诞生与演进
故事要从 Netscape 公司说起。1994 年，他们想做网上安全交易，于是设计了 SSL（Secure Sockets Layer）协议。第一版 SSL 1.0 是内部版本，从未对外公开——原因很简单，设计缺陷太多，拿不出手。
真正亮相的是 SSL 2.0，1995 年正式发布。但说实话，这个版本漏洞不少，比如存在弱密钥和中间人攻击的风险。我当时读 RFC 时看到那些已知漏洞列表，心里就想：这要是放在今天，估计连 Beta 测试都过不了。
1996 年，Paul Kocher 主导设计了 SSL 3.0，这版才算真正奠定了现代 TLS 的基础架构。你在很多教科书里看到的握手流程、证书链验证、对称加密+非对称加密的组合模式，基本都定型于 SSL 3.0。
之后 IETF 接过了标准化工作，1999 年发布了 TLS 1.0（RFC 2246），本质上就是 SSL 3.0 的小幅升级。之所以改名，是为了强调这是行业标准，不是某家公司的私有协议。2006 年 TLS 1.1 推出，主要修补了 CBC 模式的一些攻击面。2008 年的 TLS 1.2 是一次大版本升级——引入了 AEAD 加密套件，支持更灵活的哈希算法。2018 年 TLS 1.3 发布，把握手从 2-RTT 压缩到 1-RTT，甚至支持 0-RTT 模式，性能和安全都上了一个台阶。
看完这张图，你应该对演进脉络有了直观印象。我个人觉得，这里最值得关注的是 TLS 1.2 和 TLS 1.3。为什么？因为目前生产环境中，绝大多数系统都在用这两个版本。尤其是做令牌化传输，我强烈建议直接上 TLS 1.3——握手快、安全冗余少、配置也干净。
4.2 TLS vs SSL：核心差异
很多人把 TLS 和 SSL 混着叫，其实这俩本质上是同一套协议的不同版本。但严格来说，SSL 是 Netscape 的产物，TLS 是 IETF 的标准。下面这张表我列了几个关键对比维度，你一看就明白：
| 对比维度 | SSL 3.0 | TLS 1.0 | TLS 1.2 | TLS 1.3 |
|---|---|---|---|---|
| 发布年份 | 1996 | 1999 | 2008 | 2018 |
| 标准化组织 | Netscape | IETF | IETF | IETF |
| 加密算法强度 | 弱（RC4、CBC） | 中等 | 强（AEAD支持） | 最强（仅AEAD） |
| 握手延迟 | 2-RTT | 2-RTT | 2-RTT | 1-RTT / 0-RTT |
| 当前安全状态 | 已废弃，有公开漏洞 | 不建议使用 | 推荐（需合理配置） | 强烈推荐 |
这里有个细节我想强调一下：SSL 3.0 在 2014 年被曝出了 POODLE 攻击，可以直接从加密流里提取明文数据。我那时候帮客户做渗透测试，测了十几个老系统，一半以上还开着 SSL 3.0。我当时就在报告里写：「这个协议必须关，没有商量的余地。」
说白了，SSL 和 TLS 最大的差别在于：SSL 已经停更了，而 TLS 还在持续演进。你在任何新项目里都不应该再碰 SSL，直接配置 TLS 1.2 起步，最好默认 TLS 1.3。
4.3 TLS在现代网络中的地位
你想想看，现在哪个联网服务离得开 TLS？
- HTTPS：整个 Web 的信任基石，证书 + TLS 缺一不可。
- API 通信：REST、gRPC、GraphQL，底层清一色跑在 TLS 上。
- 邮件传输：SMTP、IMAP、POP3 的加密通道全依赖 TLS。
- 物联网：MQTT over TLS 已经是智能设备的标准通信方式。
- 数据令牌化传输：令牌在传输过程中必须经过 TLS 加密，否则令牌本身就成了新的泄露点。
我个人觉得，TLS 之所以能成为「网络安全的标配」，核心原因就两个：标准化成熟和生态完善。所有主流编程语言都有现成的 TLS 库——OpenSSL、BoringSSL、s2n、Mozilla NSS，你用 Python 的 ssl 模块还是 Go 的 crypto/tls，都是开箱即用。
令牌化传输中的 TLS 角色
数据令牌化本身解决的是存储层的替身问题，但令牌在网络里流动时，如果明文传输，攻击者截获令牌就能直接冒充用户。TLS 在这里负责「运输加密」——保证令牌在客户端和服务器之间不会被窃听或篡改。两层加在一起，才是完整的安全方案。
我之前在做一个金融级令牌化项目时，对方的安全审计明确要求：所有令牌相关流量必须使用 TLS 1.2 以上，且加密套件只允许 AEAD 类型（比如 TLS_AES_128_GCM_SHA256）。这个要求现在基本上成了行业共识。
4.4 核心协议原理概览
虽然是概述，但我还是想快速过一下 TLS 的核心原理，方便后面章节展开。不深入讲细节，先搭个骨架。
TLS 的工作流程可以拆成三块：
- 握手阶段：客户端和服务器协商加密版本、交换随机数、验证证书、生成会话密钥。
- 密钥交换：用非对称加密（RSA、ECDHE）安全地传输预主密钥，双方各自派生出对称密钥。
- 记录协议：用协商好的对称密钥对实际数据进行加密传输，附带 MAC 校验完整性。
举个例子。你打开一个 HTTPS 网站，浏览器先拿到服务器的证书，验证它是不是由受信任的 CA 签发的。验证通过后，双方用 ECDHE 交换密钥，最后用 AES-GCM 加密后续的 HTTP 请求和响应。整个过程对用户完全透明，但背后发生了至少 4 次网络往返（TLS 1.2）或 2 次（TLS 1.3）。
关于证书链的小经验
我曾经调试过一起握手失败的问题，查了两天才发现是中间证书没配全。服务器只发了叶子证书，没有把中间 CA 证书带上，客户端那边证书链验证到一半就断了。你如果自己部署 TLS，务必确认完整证书链——cat cert.pem intermediate.pem root.pem > fullchain.pem 这个顺序别搞反。
注意：不要混用版本
有些开发同学为了兼容老设备，会在服务器上同时开启 SSL 3.0、TLS 1.0、TLS 1.1、TLS 1.2。这种做法风险极高——攻击者会主动降级到最弱的版本发起攻击。我建议的做法是：只开 TLS 1.2 和 TLS 1.3，其他版本全部禁用。如果你确实需要兼容老旧客户端，至少把 SSL 3.0 和 TLS 1.0 关掉。
讲到这里，TLS/SSL 的概况就差不多了。记住三个关键点：SSL 已死，TLS 当立；TLS 1.2 是当前底线，TLS 1.3 是未来方向；令牌化传输必须跑在 TLS 加密通道上。后面几章我们会深入握手细节和配置实践，到时候再展开聊。