1. TLS协议基础：从SSL到TLS的演进之路
各位好，我是老周。做安全审计这些年，我见过太多因为TLS配置不当导致的漏洞。说实话，很多人连TLS和SSL都分不清就开始配证书，结果嘛……嗯，咱们先从根上把这事捋清楚。
1.1 TLS发展历史：一个关于安全的进化故事
TLS（传输层安全协议）不是凭空冒出来的。它的前身是网景公司在1994年推出的SSL协议。那时候互联网刚起步，网上传输的数据基本都是明文——你想想看，你在网页上输个密码，就跟在街上喊出来一样。
我简单梳理一下时间线：
| 版本 | 发布年份 | 关键变化 | 当前状态 |
|---|---|---|---|
| SSL 1.0 | 1994 | 从未公开发布，存在严重安全问题 | 已废弃 |
| SSL 2.0 | 1995 | 首次公开，但存在多个安全缺陷 | 已废弃（RFC 6176） |
| SSL 3.0 | 1996 | 重大改进，引入SHA-1和证书验证 | 已废弃（RFC 7568） |
| TLS 1.0 | 1999 | 基于SSL 3.0，改名并标准化 | 已废弃（RFC 8996） |
| TLS 1.1 | 2006 | 防御CBC攻击，引入显式IV | 已废弃（RFC 8996） |
| TLS 1.2 | 2008 | 支持AEAD密码套件，SHA-256 | 广泛使用 |
| TLS 1.3 | 2018 | 大幅简化握手，移除不安全算法 | 推荐使用 |
核心要点：截至2024年，SSL 2.0/3.0、TLS 1.0/1.1均已正式废弃。如果你还在用这些版本，坦白说——你的系统就是个筛子。
1.2 TLS与SSL的区别：不只是改了个名字
很多人以为TLS就是SSL的新版本，换个马甲而已。其实不然。我当年做第一个安全审计项目时，客户说他们用的是"SSL"，结果一查是TLS 1.2——这种混淆太常见了。
两者的本质区别：
- 标准化主体不同：SSL是网景公司的专有协议，TLS是IETF的开放标准（RFC）。
- 协议细节差异：TLS 1.0虽然基于SSL 3.0，但两者不兼容。TLS 1.0的握手协议中，ClientHello消息里会携带一个特殊的版本号字段，SSL 3.0不会。
- 密码套件支持：TLS引入了更灵活的密码套件协商机制，SSL的套件列表是固定的。
- 安全强度：TLS 1.2开始强制要求支持AEAD（认证加密），SSL时代根本没有这概念。
我的建议：做安全审计时，别信对方说的"我们用的是SSL"。直接抓包看ClientHello里的版本号，或者用openssl s_client连一下，结果说话。
1.3 TLS握手协议概述：一次加密会话的建立过程
握手协议是TLS最核心的部分。说白了，就是客户端和服务器在正式传输数据之前，先互相打个招呼、亮个身份、商量好用什么加密方式。这个过程我拆成几步来讲。
以TLS 1.2的完整握手为例：
- ClientHello：客户端发消息，告诉服务器它支持的TLS版本、密码套件列表、以及一个随机数。
- ServerHello：服务器从客户端提供的列表中选一个密码套件，发回自己的随机数。
- Certificate：服务器发送自己的数字证书（包含公钥）。
- ServerKeyExchange：如果需要（比如使用DHE/ECDHE密钥交换），服务器发送额外的密钥参数。
- ServerHelloDone：服务器说"我这边发完了"。
- ClientKeyExchange：客户端生成预主密钥（Pre-Master Secret），用服务器的公钥加密后发过去。
- ChangeCipherSpec：双方各自通知对方"我要开始用协商好的密钥加密了"。
- Finished：双方发送一条加密的验证消息，确认握手过程没有被篡改。
下面这张图能帮你直观理解整个流程：
避坑指南：我曾经遇到过一个案例，某电商平台的TLS握手总是超时。排查了半天，发现是防火墙把ServerKeyExchange消息当成了恶意流量给拦截了。所以做审计时，别忘了检查中间设备对TLS流量的处理策略。
1.4 TLS记录协议概述：数据是怎么被保护的
握手协议搞定之后，真正的数据传输就交给记录协议了。记录协议是TLS的底层传输机制，它负责把上层数据（比如HTTP请求）分片、压缩（可选）、加密、加上消息认证码（MAC），然后发出去。
记录协议的结构很简单：
struct {
ContentType type; // 内容类型（20=ChangeCipherSpec, 21=Alert, 22=Handshake, 23=Application Data）
ProtocolVersion version; // 协议版本（如TLS 1.2为0x0303）
uint16 length; // 负载长度
opaque fragment[TLSPlaintext.length]; // 实际数据
} TLSPlaintext;记录协议的处理流程：
- 分片：把上层数据切成不超过2^14字节（16KB）的块。
- 压缩：在TLS 1.3之前可选，但实际中很少用（压缩有安全风险，比如CRIME攻击）。
- 添加MAC：计算消息认证码，防止数据被篡改。
- 加密：使用握手阶段协商好的对称密钥加密数据。
- 添加记录头：加上类型、版本、长度字段，形成最终的记录。
实战经验：做渗透测试时，我经常手动构造畸形的TLS记录来测试服务器的健壮性。比如把长度字段改成0xFFFF，看看服务器会不会崩溃——有些实现确实会。这种测试在安全审计中很有价值。
1.5 本章小结
好了，TLS的基础框架咱们过了一遍。从SSL到TLS的演进，说白了就是安全攻防的缩影——攻击者不断找到新漏洞，协议设计者不断打补丁。握手协议负责建立信任，记录协议负责保护数据，两者缺一不可。
我个人习惯在开始任何TLS审计之前，先用Wireshark抓一次完整的握手包，看看实际协商的版本和密码套件。这一步能帮你快速定位80%的配置问题。记住，纸上谈兵不如动手抓包。