一、TLS协议基础
聊TLS加密流量处理之前，得先把协议本身摸透。我最早接触TLS是给一个金融APP做流量审计，那时候抓包一看全是乱码，才意识到不懂协议根本没法往下走。这一章我们就从历史、结构、握手三个维度把它讲清楚。
1.1 TLS发展历史
为什么要看历史？说白了，版本变迁就是安全攻防的缩影。你想想看，一个协议从出现到现在经历了快30年，每个版本都在修补前一个的漏洞。
| 版本 | 年份 | 主要变化 | 安全状态 |
|---|---|---|---|
| SSLv2 | 1995 | 首个商用安全协议 | 已废弃，严重漏洞 |
| SSLv3 | 1996 | 修复v2问题，增加握手流程 | 已废弃（POODLE攻击） |
| TLS 1.0 | 1999 | RFC 2246，实际是SSLv3改进版 | 仍存在一些安全弱点 |
| TLS 1.1 | 2006 | 防CBC攻击，增IV显式传递 | 基本安全，但效率低 |
| TLS 1.2 | 2008 | 支持多种加密套件，SHA256 | 当前主流，广泛使用 |
| TLS 1.3 | 2018 | 简化握手，前向安全强制 | 最新，高性能高安全 |
我记得刚做安全那会儿，遇到最多的就是TLS 1.0的流量。当时很多银行系统还在用这个版本，不得不做兼容处理。后来POODLE漏洞曝光才逼着大家升级。经验告诉我：能上1.2就别降级，有条件直接上1.3。
避坑指南：我曾经在项目中见过客户为了兼容老旧IE浏览器，把服务端TLS版本降到SSLv3，结果没半年就被通报安全漏洞。记住：SSLv2/v3已经彻底不可用了，TLS 1.0也建议尽快关闭。
1.2 协议栈结构
TLS协议栈其实就两层，但很多人容易搞混。我习惯这么理解：下面一层是运输层（TCP > 记录协议），上面一层是协议族（握手、警报、密码变更）。
- 记录协议（Record Protocol）：底层封装，负责分段、压缩、加密和完整性校验
- 握手协议（Handshake Protocol）：协商加密参数、认证对方身份
- 警报协议（Alert Protocol）：传输错误和警告信息
- 改变密码规范协议（Change Cipher Spec Protocol）：通知对方切换加密参数
嗯，这里要注意：记录协议是所有上层协议的基础。握手数据、应用数据最终都会被记录协议封装成TLS记录。你抓包看到的TLS片段，本质上就是记录协议帧。
1.3 握手流程概览
握手就是TLS建立安全信道的过程。为什么叫握手？因为双方要互相“认识”、互相验证、再商量好用什么钥匙。说白了，就是一次加密版自我介绍。
- ClientHello：客户端发送支持的TLS版本、加密套件列表、随机数
- ServerHello：服务器选择加密参数，返回会话ID和服务器随机数
- Certificate：服务器发送数字证书（内含公钥）
- ServerKeyExchange：如需密钥交换（如DHE），服务器发送相关参数
- ServerHelloDone：服务器表示第一阶段结束
- ClientKeyExchange：客户端发送预主密钥，用服务器公钥加密
- ChangeCipherSpec：客户端通知切换加密模式
- Finished：客户端发送握手完整性校验
- ChangeCipherSpec（服务器端）：服务器同样切换模式
- Finished（服务器端）：服务器完成握手
经验之谈：握手过程看似很长，但实际只需1~2个RTT。TLS 1.3把步骤合并后甚至能做到0-RTT。我建议你做流量分析时重点关注ServerHello和Certificate这两个包，大部分配置问题都出在这里。
我在项目中调试过很多次握手失败的情况。最常见的原因是证书链不完整，服务端只发了叶子证书没发中间CA证书，客户端校验直接拒绝。你遇到这种情况，先确认证书是否包含全部中间链。另外，
核心要点：
- 握手是TLS的基础，所有加密参数都在这里协商
- 版本向下兼容但不安全，能用TLS 1.2就别开老版本
- 证书必须包含完整链（叶子 + 中间CA + 根CA，但根CA通常不在线传输）
- 随机数用于生成会话密钥，保证每次握手结果唯一
举个实际例子：一次我审计某教育平台流量，发现他们用的TLS 1.0加密套件还是RC4。当时就提醒他们升级，因为RC4已经被证明有偏斜攻击。后来改了TLS 1.2+AES-GCM才通过合规审查。
这一章我尽量用最简的方式给你建立TLS的整体认知。接下来的内容会更深入，比如密钥交换细节、证书链验证、会话复用等。但基础不牢地动山摇，先把版本、协议栈、握手流程印在脑子里再往深走。