TLS 协议概述与迁移背景

聊 TLS 迁移，得先搞清楚 TLS 到底是什么。说白了，它就是给网络通信加一把锁——加密、认证、完整性保护，缺一不可。我最早接触 TLS 是在做支付系统的时候，那时候还不叫 TLS，叫 SSL。后来才知道，这俩东西渊源很深，但本质目标一直没变：让数据在网络上安全地跑。

TLS 协议发展历程

从 SSL 到 TLS，差不多走了三十年。我整理了一下关键节点，你看下面这张表就清楚了：

你看，TLS 1.3 是 2018 年才定稿的，距离 1.2 整整隔了十年。这十年里，安全攻击手段翻了好几倍——比如 CRIME、Lucky13、ROBOT……我当年维护一个老系统，跑的是 1.0，被安全扫描扫出十几个高危漏洞，领导催着整改，那个头大啊。

为什么会这样？因为协议越老，用的算法越旧。比如 RC4 流密码、CBC 模式下的 MAC 填充校验，这些在现代攻击面前根本撑不住。我个人习惯是：新项目直接上 TLS 1.3，老项目起码得提到 1.2，并且把弱套件关干净。

为什么需要迁移

迁移有两大驱动力：安全漏洞和性能提升。我一个个说。

安全漏洞——不得不走的坑

你想想看，一个网站还在用 TLS 1.0，攻击者用一个 BEAST 攻击就能解密 cookies。听起来夸张？但我真见过某银行内部系统就因为没升级，被渗透测试团队抓了个正着。常见的漏洞包括：

• POODLE（SSL 3.0）：利用 CBC 填充漏洞，可以窃取明文。
• BEAST（TLS 1.0）：利用 IV 猜测，逐字节解密。
• Lucky13（CBC 模式）：侧信道攻击，通过响应时间差推导明文。
• ROBOT（RSA 密钥交换）：利用 Bleichenbacher 攻击，暴露私钥。

这些漏洞听起来都像代号游戏，但每个都在真实场景中造成了数据泄露。嗯，这里要注意——不要以为只有老旧系统才出问题。我曾经遇到一个项目，他们把服务从 1.0 升级到 1.2，但忘了禁用 TLS 1.0 fallback，结果中间人攻击直接降级到了 1.0，相当于白干。

性能提升——不止是安全，还更快

TLS 1.3 相比 1.2，握手次数从两次往返(RTT)降到一次，甚至 0-RTT。这意味着什么？用户打开网页更快了，服务器 CPU 负载也下来了。

我亲身经历：某电商网站迁移到 1.3 后，首屏加载时间减少了 30%~40%。因为 1.3 砍掉了不少不必要的协商步骤，比如公钥证书可以缓存，加密套件数量从几百种压缩到 5 种。说白了就是少做无用功。

迁移项目的整体目标

好了，前面铺垫这么多，那一个 TLS 迁移项目到底要达成什么？我总结成三个核心目标：

1. 协议面升级：关闭 TLS 1.0/1.1，启用 1.2 并最终推进到 1.3。
2. 密码套件清理：移除所有弱加密套件（RC4、CBC、3DES、DSS），只保留 AEAD 套件（AES-GCM、ChaCha20-Poly1305）。
3. 配置与运营自动化：证书自动化续期（ACME/Let's Encrypt）、合规扫描、变更流程标准化。

这三个目标听起来简单，实际做起来坑很多。比如有些中间件不兼容 1.3 的加密套件协商逻辑，得打补丁或者升级版本。我曾经在迁移一个 Java 微服务时，发现它用的旧版 Bouncy Castle 不支持 ChaCha20，足足折腾了两个星期。