TLS握手过程与密码套件分析教程 - 第1节
1.1 TLS 到底是什么？
先从一个最朴素的场景说起吧。
你打开浏览器，输入网址，几秒后页面加载出来。这中间发生了啥？你的电脑跟服务器之间，要交换一堆数据。如果这些数据是明文传输的，那就像在大街上把银行卡密码喊出来——谁都能听走。
TLS（Transport Layer Security）就是给这条通信链路加个加密隧道。它让你和服务器之间的数据，只有你俩能看懂。窃听者抓到的全是乱码。
我刚开始接触网络安全时，总以为 TLS 就是个“加解密库”。后来踩了坑才明白——它是一套完整的握手协议，负责协商加密算法、交换密钥、验证身份，然后才进入加密传输。说白了，它先“聊”好用什么密码本，再开始说悄悄话。
1.2 为什么需要 TLS？—— 三个核心问题
你想想看，明文通信会面临什么风险？
- 窃听：中间人抓到你的登录密码、信用卡号。
- 篡改：攻击者偷偷修改你下载的软件，插入恶意代码。
- 冒充：你以为是银行官网，其实是个钓鱼站点。
TLS 用三种技术一一解决：
- 加密（对称加密） → 防窃听
- 消息认证码（MAC） → 防篡改
- 数字证书（公钥基础设施） → 防冒充
嗯，这就是最核心的三板斧。我在一次线上故障排查中遇到过：服务器突然报证书过期，整个支付链路断了。当时才意识到，证书管理跟代码一样需要做生命周期运维。
1.3 从 SSL 到 TLS：一部血泪进化史
这个故事要从 1994 年说起。
1.3.1 史前时期：SSL 1.0（从未发布）
网景公司内部搞了个原型，漏洞太多，直接毙掉了。我猜当时他们也没想到，这个未面世的产品会成为现代互联网安全的基础。当年很多人还觉得“互联网上谁要偷你数据啊”？真是天真。
1.3.2 SSL 2.0（1995）—— 第一代产品，但很脆弱
1995 年发布在 Netscape Navigator 中。它支持了基本握手和加密，但设计缺陷明显：
- MAC 和加密绑在一起（先加密后 MAC ← 顺序错误，易被攻击）
- 使用弱哈希（MD5）
- 没有证书链验证
后来被 DROWN 攻击一锅端。我建议：现在任何系统都不要启用 SSL 2.0，连兼容性选项都不要开。
1.3.3 SSL 3.0（1996）—— 重大升级
改进了很多：引入了更安全的 HMAC，支持密码套件协商，握手流程基本定型（ClientHello → ServerHello → 证书交换 → 密钥协商 → Finished）。这个版本一直用到 2015 年才被正式废弃，因为 POODLE 攻击。
这里有个经验：即使协议版本没有被官方废弃，一旦公开了实用攻击手法，就应该立刻禁用。我曾经在内部审计时发现某老旧系统还开着 SSL 3.0，紧急通知下线，才避免了一次合规风险。
1.3.4 TLS 1.0（1999）—— 改个名，但不止是改名
IETF 接手了 SSL，把名字改成 TLS 1.0。改动不大，但标志着标准化开始。TLS 1.0 兼容 SSL 3.0，只是改了点细节（比如 HMAC 默认算法改成 SHA-1，增加了一些警报机制）。这个版本至今还在很多老旧系统里——其实它已经不安全了，应该用 TLS 1.2 或更高。
1.3.5 TLS 1.1（2006）—— 小步快跑
主要改进：
- 防 CBC 攻击（增加显式 IV）
- 限制填充长度
- 对 BEAST 攻击做了初步防御
但说实话，这个版本没有太大存在感。我当时配置服务器时，通常直接跳 1.1，从 1.0 升到 1.2。
1.3.6 TLS 1.2（2008）—— 黄金时代，至今的主流
这次改动非常大：
- 移除 MD5/SHA-1 作为默认哈希
- 支持 GCM、CCM 等 AEAD 密码
- 引入 椭圆曲线密码（ECDHE、ECDSA）
- 密码套件可扩展性更好
到现在（2025年），TLS 1.2 依然是部署最广的版本。我自己的生产环境，只要兼容性允许，我优先开 TLS 1.2 和 1.3。
1.3.7 TLS 1.3（2018）—— 大提速，更安全
握手从 2-RTT 降到 1-RTT（甚至 0-RTT），移除了一大堆过时算法（RSA 密钥交换、CBC 模式、RC4 等）。强制使用前向安全的密钥交换（DHE/ECDHE），且只有 5 个密码套件可选。
说实话，TLS 1.3 的设计哲学就是“少即是多”。删除比新增更难，IETF 做到了。
下面这张图概括了整个演进路线：
1.4 各版本关键特性对比
| 版本 | 发布时间 | 主流算法 | 前向安全 | 安全性评价 | 当前状态 |
|---|---|---|---|---|---|
| SSL 2.0 | 1995 | RC4, MD5 | ✗ | 极差 | 已废弃 |
| SSL 3.0 | 1996 | RC4, 3DES, SHA-1 | 受限 | 差 (POODLE) | 已废弃 |
| TLS 1.0 | 1999 | RC4, CBC, SHA-1 | 受限 | 差 (BEAST) | 不推荐 |
| TLS 1.1 | 2006 | CBC, SHA-1 | 受限 | 一般 | 不推荐 |
| TLS 1.2 | 2008 | AES-GCM, ECDHE, SHA-256 | ✓ (ECDHE) | 好 | 推荐 |
| TLS 1.3 | 2018 | AEAD-only, ECDHE, EdDSA | ✓ (强制) | 优秀 | 强烈推荐 |
这个表格你一定要保留一份，做安全基线检查时直接对照。我每次给客户做安全评审，第一件事就是让他们导出一份当前支持的TLS版本列表，然后按这个表一条条砍掉不安全的。
1.5 我的几点经验与思考
- 兼容性陷阱：我曾经帮一个银行升级老系统，发现他们还在用 TLS 1.0 对接第三方支付。对方后端是 2005 年的古董，升到 1.2 直接连不上。最后只能在一台专用前置机上保留 1.0，且只绑定特定 IP。这种做法能应急，但不推荐长期使用。
- 密码套件的选择：别用“默认配置”。很多中间件（Nginx、Tomcat）默认启用了大量老旧套件。我建议只保留 ECDHE + AES-GCM + SHA-256 系，外加一个 ECDHE + CHACHA20-POLY1305 做备选。
- 工具链：多用
openssl s_client和ssllabs.com做测试。我习惯在部署前问自己：如果我的证书明天就过期，自动续签机制准备好了吗？