TLS与SSL：从血缘到进化
很多刚接触加密协议的同学都会问：TLS 和 SSL 到底啥关系？是不是同一个东西换个名字？
嗯，我刚开始做 HTTPS 抓包分析那会儿也迷糊过。当时项目要求禁用 SSL 3.0，我还在想“SSL 3.0 不就是 TLS 1.0 吗？”结果被安全审计打回来重改。说白了，它们之间是父子关系，但儿子长大后改了族谱。
SSL 的诞生：网景的先锋实验
1994 年，网景公司推出了 SSL 1.0。不过这个版本从未公开发布——内部测试时就发现有严重安全漏洞，直接废掉了。
1995 年，SSL 2.0 随 Netscape Navigator 1.1 浏览器面世。它第一次实现了在 HTTP 之上加密传输，但问题也不少：比如使用 MD5 做消息认证、没有证书链验证、容易遭受中间人攻击。
1996 年，SSL 3.0 发布。它修复了 2.0 的大部分问题：增加了证书链验证、改用 HMAC、支持 renegotiation。我记得当年很多政府网站强制要求 SSL 3.0，直到 2014 年 POODLE 漏洞爆出来才全面淘汰。
改名的转折点：标准化之路
1999 年，IETF（互联网工程任务组）接手了 SSL 的标准化工作。因为他们不是网景公司，不能直接用“SSL”这个名字——商标在网景手里。于是改名为 TLS（Transport Layer Security），版本号也从 1.0 开始。
但你不能说 TLS 1.0 就是 SSL 3.0。它们握手的消息格式、密钥派生算法、记录层协议都有细微差别。比如 TLS 1.0 的 PRF（伪随机函数）使用了 HMAC-MD5 和 HMAC-SHA1 双路混合，而 SSL 3.0 用的是自己的 HMAC 变种。这在互操作性上坑过不少人——我调试过一台老交换机，它在握手的 ServerHello 里写的是“SSL 3.1”，但实际走的是 TLS 1.0 的密钥计算，结果和 OpenSSL 1.0.1 死活协商不上。
版本演进时间线
我习惯用一张图和一个表格来理清脉络。先看整体演化关系：
版本对照表
下面这张表把每个版本的发布年份、核心改进、当前状态列清楚。我在做安全合规审计时经常要翻这个表——比如政府客户要求“必须使用国家密码局认可的 TLS 1.2 及以上”，你至少得知道 1.2 是哪一年出的。
| 版本 | 发布年份 | 核心改进（相对于前一版） | 当前状态 |
|---|---|---|---|
| SSL 1.0 | 1994（未公开） | 网景内部原型，未修复安全漏洞即废弃 | 从未发布，无关 |
| SSL 2.0 | 1995 | 第一个公开版；支持基本加密和认证；弱点是 MD5、无证书链验证、易中间人攻击 | ❌ 2011年 RFC 6176 明确禁用 |
| SSL 3.0 | 1996 | 增加证书链验证、HMAC、变更密钥派生算法；修复 2.0 主要漏洞 | ❌ 2014年 POODLE 漏洞后禁用 |
| TLS 1.0 | 1999 | 改名；PRF 改为双路 HMAC；记录层增加版本字段；移除 Fortezza 套件 | ❌ 2021年起大多数浏览器拒绝 |
| TLS 1.1 | 2006 | 增加显式 CBC IV 防止 BEAST 攻击；引入 Cipher Block Chaining 保护 | ❌ 2020年起主流禁用 |
| TLS 1.2 | 2008 | 支持 AEAD（GCM/CCM）；SHA-256 哈希；可扩展的密码套件协商；移除 ID 密码套件 | ✅ 当前推荐最低版本 |
| TLS 1.3 | 2018 | 握手从 2-RTT 减为 1-RTT（首次）或 0-RTT（恢复）；弃用 RSA 密钥交换、静态 DH；仅支持 AEAD | ✅ 最新标准，强烈推荐 |
关键差异：SSL 3.0 与 TLS 1.0 到底哪里不同？
很多老工程师习惯把 TLS 1.0 叫做 SSL 3.1，但从规范角度看，它们有至少三个重要区别：
- 记录层版本号不同：SSL 3.0 的 ContentType 后跟版本号 0x03,0x00；TLS 1.0 是 0x03,0x01。抓包时看一眼 Protocol Version 字段就能区分。
- 密钥派生算法不同：SSL 3.0 的 PRF 是自己的 HMAC 变种；TLS 1.0 改用 HMAC-MD5 + HMAC-SHA1 双路混合。计算出来的 Master Secret 不一样。
- Finished 消息不同：SSL 3.0 的 Finished 消息直接放 MD5+SHA1 的散列；TLS 1.0 用了 PRF 进一步混淆。
我记得在维护一个银行旧系统时，对方硬说他们只支持 TLS 1.0，但抓包看握手 ClientHello 里的版本号是 0x03,0x00 —— 其实是 SSL 3.0。管理员坚持不改配置，结果我只好在 Nginx 里手动补了个 ssl_protocols SSLv3 TLSv1 才连上，但安全扫描直接亮红灯。
SSLv3，哪怕是为了兼容。标准做法是只写 TLSv1 TLSv1.1 TLSv1.2 TLSv1.3。如果必须兼容老设备，至少用 TLSv1 而不是 SSLv3——前者和后者的协议栈实现有细微差别，但安全性好一个数量级。
版本选择的现实考量
我个人建议直接上 TLS 1.2 或 1.3。如果你维护的是政府或金融系统，按照国家标准（如 GB/T 38636-2020 或等保 2.0），必须支持 TLS 1.2 以上，且密码套件要使用国密 SM2/SM3/SM4。注意：TLS 1.3 目前官方还没有国密套件的标准扩展（2025年仍在草案阶段），所以国内合规场景通常只启用 1.2。
为什么 1.3 不能随便和国密混用？原因在于 1.3 强制使用 AEAD 加密，而国密套件里的 SM4-GCM 虽然算 AEAD，但 TLS 1.3 的 key schedule 和 1.2 完全不同，需要专门的扩展支持。这个坑我在做信创适配时踩过——OpenSSL 1.1.1 默认不支持 SM4-GCM 在 1.3 中的协商，导致国密网关和标准浏览器握手失败。
弃用列表（2025年视角）
你作为网安工程师，应该记住一条底线：任何 SSL 版本和 TLS 1.0/1.1 都不应该再出现在生产环境。我见过某些老旧打印机、工控设备还在用 SSL 3.0，这种设备要么隔离在独立网段，要么彻底升级固件。下面是实际项目中的弃用判定标准：
- ✅ 可安全使用：TLS 1.2（配置严格套件）、TLS 1.3
- ⚠️ 仅内部兼容使用（需额外防护）：TLS 1.1（2020年后禁用）
- ❌ 完全不推荐：TLS 1.0、SSL 3.0、SSL 2.0
我曾经给一个电商平台做渗透测试，发现他们 CDN 回源到后端使用了 SSL 3.0（因为后端是 2012 年的 Java 1.6 跑 Tomcat 7）。攻击者利用 POODLE 漏洞，几分钟就解出了 Cookie 中的 Session ID。客户当时就崩溃了——换 Java 版本 + 升级 Tomcat + 配置 TLS 1.2 整了半个月。说白了，保留老版本协议的代价远远超过升级成本。
总结一下核心关系
不想看太多细节的，记住三条：
- SSL 是 TLS 的前身。TLS 1.0 ≈ SSL 3.1，但两者不完全兼容，需要协商降级。
- 版本跳跃不要跳过推荐。从 1.2 到 1.3 算是最大的一次重构，砍掉了很多旧特性（RSA key exchange、静态 DH、CBC 模式等）。
- 安全基线在持续前移。2025 年的标准是只开启 TLS 1.2（充分配置）和 TLS 1.3。我自己的服务器配置里直接写死了
ssl_protocols TLSv1.2 TLSv1.3;，没有回退选项。