TLS协议基础：握手、证书、加密套件
做DLP策略的人，经常碰到一个头疼的问题——流量加密了，内容看不见。这时候如果不懂TLS的底层逻辑，策略基本就是瞎配。所以这一章我们好好聊聊TLS握手、证书和加密套件。别急，我会把关键点拆开讲，中间穿插一些我踩过的坑。
1. TLS握手——加密通道的“敲门砖”
TLS握手说白了就是客户端和服务器在正式通信前，先互相打个招呼、确认身份、然后约定一把对称密钥。整个过程发生在TCP三次握手之后。嗯，这里要注意：握手阶段的流量是明文的，只有完成握手后才开始加密传输——这对DLP策略来说是关键窗口期。
我记得有一次帮一家银行做DLP审计，发现他们的TLS握手阶段采集参数没开，结果所有加密流量都只能按“unknown”处理，策略命中率直接掉了30%。后来补上SNI解析和证书提取，效果立竿见影。
一个典型的TLS 1.2握手流程大致如下（我用SVG画了张图，方便你记）：
从图里你能看到，整个过程有五个核心消息交换。我个人习惯把第三步“证书验证”和第四步“密钥交换”看作安全性的基石——前者保证对方身份合法，后者保证即使证书被偷也无法解密历史流量（前向安全性就是在这步通过ECDHE实现的）。
2. 证书体系——谁在背后“担保”？
证书本质上是一个数字身份证。里面包含公钥、主体信息、颁发机构、有效期等。但真正让证书起作用的，是PKI（公钥基础设施）的信任链。你想想看，如果客户端随便信任一个声称是“支付宝”的证书，那整个加密就是笑话。所以业界搞了CA（证书颁发机构）体系。
| 证书类型 | 信任基准 | 典型用途 |
|---|---|---|
| 根证书/Root CA | 预埋在操作系统/浏览器中 | 签发下级证书，不可直接签发用户证书 |
| 中间证书/Intermediate CA | 由根证书签发 | 签发最终实体证书，增加安全性（根证书可离线） |
| 终端证书/Leaf Certificate | 由中间或根证书直接签发 | 网站、服务器、客户端的真实身份凭证 |
| 自签名证书 | 自我签发，需手动导入信任 | 内部开发测试、私有网络设备管理 |
做DLP策略时，经常会遇到自签名证书或内部CA签发的证书。有一次我帮一家电商公司部署TLS解密，他们内部系统用了自签名证书，结果DLP策略因为证书不可信直接丢弃了这些流量。解决方案其实简单——把内部CA的根证书导入DLP设备的信任库。但是，很多团队忘了这一步，排查半天才发现。
3. 加密套件——密码算法的“组合菜单”
加密套件是一组密码算法的集合，规定了密钥交换、身份验证、对称加密、消息认证码（MAC）分别用什么算法。比如常见的 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256，拆开看：
- ECDHE — 密钥交换和握手时的数字签名（椭圆曲线DH + RSA签名）
- AES_128_GCM — 对称加密算法（128位AES，GCM模式提供认证加密）
- SHA256 — PRF（伪随机函数）和MAC使用的哈希算法
写DLP策略时，套件的选择直接影响你能否做深度包检测。举个例子：如果你必须用TLS 1.3，那握手过程简化了很多，而且很多套件被强制要求使用前向安全算法。对于DLP来说，这意味着你无法再从握手阶段获取完整的密钥交换信息，必须依赖其他机制（如TLS代理、浏览器插件）来完成解密。
常见的加密套件强度对比可以看这个表（注意：DLP策略建议只允许强套件）：
| 套件名称 | 前向安全 | 对称加密 | 推荐等级 |
|---|---|---|---|
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | ✅ 是 | 256-bit AES GCM | ⭐⭐⭐⭐⭐ |
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | ✅ 是 | 128-bit AES GCM | ⭐⭐⭐⭐⭐ |
| TLS_RSA_WITH_AES_128_CBC_SHA | ❌ 否 | 128-bit AES CBC | ⭐⭐（不推荐） |
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA | ✅ 是 | 112-bit 3DES | ⭐（已弃用） |
看到没？前向安全算法（ECDHE、DHE）对于DLP策略也很重要——因为这些算法生成的会话密钥只保存在内存中，即使后期拿到私钥也无法解密历史流量。反过来，对于需要做TLS解密的网关来说，前向安全意味着必须介入握手过程（比如作为中间人）才能拿到会话密钥。这就引出了DLP策略中常见的“SSL/TLS代理”方案——不过那是后面章节的事，这里先记住原理。