为什么版本选择这么重要？
说真的，我见过不少团队在 TLS 版本上吃了大亏。有的为了兼容老系统死抱着 SSL 3.0 不放，结果被 POODLE 攻击打得措手不及；有的盲目切到 TLS 1.3，结果中间件不支持，业务直接挂了。版本选错了，安全性和可用性两头空。
这一章，我就带你把这几个版本掰开揉碎看一遍。不只是背表格，我会把我在线上压测、合规审计、应急响应时踩过的坑都讲出来。你读完心里就有数了：什么场景该用什么版本，什么时候必须下狠心砍掉旧版本。
SSL 3.0：早该入土的遗产
SSL 3.0 是 1996 年的东西了。当年设计它的时候，互联网还没现在这么凶险。但放到今天，它浑身都是漏洞。
- POODLE 攻击（CVE-2014-3566）：利用 CBC 模式填充 oracle，中间人能解密 HTTPS 流量。我 2015 年帮一个金融客户做渗透测试，就靠这个漏洞直接读到了用户的 session cookie。
- RC4 偏好问题：很多客户端降级协商时会选 RC4，但 RC4 早已被证明有严重偏差。
- 不支持 AEAD：没法用 GCM、CCM 这类现代认证加密。
我唯一一次看到 SSL 3.0 还有用的场景，是某工业控制系统里一个固化在嵌入式设备上的老协议栈，厂商已经倒闭了。那属于“物理隔离 + 没法改”的极端情况。正常的 Web 服务、API 网关，别碰它。
TLS 1.0 & 1.1：过渡期的妥协产物
TLS 1.0 是 1999 年出的，1.1 是 2006 年。它们比 SSL 3.0 好一些，但放到今天仍然不够用。
| 特性 | TLS 1.0 | TLS 1.1 | 对比 |
|---|---|---|---|
| CBC 模式防御 | 无 | 隐式 IV | 1.1 防了大部分 BEAST 变种，但不够完整 |
| RC4 支持 | 是 | 是 | 两个都该禁用 |
| 压缩方法 | 支持 | 支持 | CRIME/BREACH 攻击的根源 |
| AEAD 支持 | 无 | 无 | 不能使用 GCM |
| PCI DSS 合规 | 已禁止 (v4.0) | 已禁止 (v4.0) | 2024 年起全面失效 |
2020 年，主流浏览器（Chrome、Firefox、Edge）都开始对 TLS 1.0/1.1 弹出“不安全”提示。2021 年 RFC 8996 正式将它们标记为历史。我个人在 2022 年帮客户做等保测评时，发现很多政务网站还开着 TLS 1.0，原因是后台的 Windows Server 2008 R2 不支持更高版本。那只能先升级操作系统，再关版本。
TLS 1.2：当前的主力，但也要退役
TLS 1.2 是 2008 年发布的。它支持了 AEAD、扩展 Master Secret、SNI 等现代特性。说实话，它是目前部署最广的版本，而且暂时还安全。
- 优点：灵活，支持 GCM、CCM、ChaCha20-Poly1305；可以配合 ECDHE 做前向安全；所有主流客户端和服务端都支持。
- 缺点：协议协商过程还是两轮 RTT（TCP + TLS），延迟较高；协商过程中明文传输的 ServerHello 可能被降级攻击；密码套件多到让人头大，配置错误概率高。
我的习惯是：所有新系统默认只开 TLS 1.2 和 1.3，并且明确列出允许的密码套件。不写“HIGH:!aNULL:!eNULL”这种模糊字符串，而是给出具体列表。
# Nginx 配置示例
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
ssl_prefer_server_ciphers on;
注意 ssl_prefer_server_ciphers on —— 你想想看，如果不打开这个，客户端可能会选一个弱的密码套件，前向安全就废了。
TLS 1.3：快、安全、精简
TLS 1.3 是 2018 年发布的（RFC 8446）。它最大的变动是砍掉了大量不安全的密码套件，只保留五个 AEAD 套件。
- 握手延迟 1-RTT（甚至 0-RTT 用于重复连接）。我测过，开启 TLS 1.3 后，同一条链路的 HTTPS 请求建立时间从 120ms 降到了 40ms。
- 前向安全强制：所有密钥交换都必须用 (EC)DHE，没有 RSA 静态密钥交换。这意味着即使日后私钥泄露，之前截获的流量也无法被解密。
- 删除了压缩、重协商、静态 RSA/ DH 等危险特性。配置大大简化。
当然，0-RTT 有重放攻击风险。RFC 8446 要求服务器限制 0-RTT 只用于幂等请求。我曾经在电商 API 上用 0-RTT 做订单查询，但没做幂等性检查，结果压力测试时同一个请求被重放生成了多笔订单。嗯，后来我加了 nonce 去重。
# OpenSSL 1.1.1 以上版本默认支持 TLS 1.3
# 测试服务端是否支持
openssl s_client -connect example.com:443 -tls1_3
弃用策略：手把手教你制定时间线
我建议不要一刀切，也别拖太久。分四步走：
- 审计现状：用 SSLLabs 或 openssl 检查所有端点支持的版本。我发现很多负载均衡器上开了 1.0 但没人知道。
- 确定时间节点：比如 2025 年 Q1 禁用 TLS 1.0/1.1，Q3 禁用 SSL 3.0。给业务方足够的通知期。
- 灰度关闭：先在测试环境关掉，跑自动化回归测试。线上先关某一个版本，观察错误日志一周。我习惯在 Nginx 的 error.log 里 grep “TLS version” 的告警。
- 启用监控告警：如果突然有大量客户端协商失败，可能是老旧设备没升级。设置阈值告警，及时回滚。
一张图理清版本进化和弃用路径
下面这个 SVG 图把五个版本的时间线、安全状态、弃用建议连起来了。你可以用来做内部培训材料。
总结一下核心行动点
- SSL 3.0：立刻关，别犹豫
- TLS 1.0/1.1：制定 3~6 个月关闭计划，配合客户端升级
- TLS 1.2：保留但限制密码套件，逐步向 1.3 迁移
- TLS 1.3：新系统默认开启，老系统尽快适配
版本选择不是一次性的。每半年扫一次你的证书和协议配置，我个人的定时提醒就设在每年四月和十月。安全这东西，偷懒一次可能就要通宵救火。你记住这个节奏就好。