1. TLS协议基础
咱们做DSPM平台TLS审计模块，第一个绕不开的就是TLS协议本身。我刚开始接触这东西的时候，觉得不就是HTTPS加个锁嘛，直到有一次帮客户排查数据库连接失败，抓包一看，对方只支持TLS 1.0——嗯，那会儿漏洞已经公开好几年了。从那以后我就养成个习惯：先搞清楚底层版本和握手细节，再去配审计规则。
1.1 TLS版本演进
TLS从1999年的1.0版走到今天，说白了就是一部「补丁史」。
| 版本 | 发布年份 | 关键变化 | 安全状态 |
|---|---|---|---|
| SSL 3.0 | 1996 | 奠定TLS基础，但设计缺陷多 | 已废弃（POODLE攻击） |
| TLS 1.0 | 1999 | 基于SSL 3.0小幅改进 | 不推荐（BEAST攻击） |
| TLS 1.1 | 2006 | 引入CBC防御机制 | 不推荐（仍存在Lucky13） |
| TLS 1.2 | 2008 | 支持AEAD、GCM、SHA-256 | 目前主力，逐步过渡 |
| TLS 1.3 | 2018 | 精简握手、移除不安全算法 | 推荐启用 |
⚠️ 重要提醒：我记得2020年有个金融客户的审计脚本还硬编码了TLS 1.0的密码套件，结果被合规检查卡住。咱们做DSPM审计配置时，强烈建议把TLS 1.0/1.1列为告警项，TLS 1.2设为最低要求。
1.2 握手流程
你想想看，客户端和服务端要安全通信，得先互相认识、交换密钥、确定加密算法——这个过程就是握手。TLS 1.2的握手需要2个RTT，TLS 1.3砍到1个RTT，甚至0-RTT（带之前缓存的会话）。
我挑最常用的TLS 1.2完整握手讲一下：
- ClientHello – 客户端发送支持的版本、密码套件列表、随机数。
- ServerHello – 服务端选择版本和套件，发回自己的随机数和证书。
- 证书验证 – 客户端检查证书链和吊销状态（OCSP）。
- 密钥交换 – 用RSA或DH/ECDHE交换预主密钥，双方算出主密钥。
- ChangeCipherSpec – 通知对方后面要用协商好的加密参数。
- Finished – 双方验证之前所有握手消息的完整性。
💡 实战经验：我曾经在调试一个内部系统时，发现每次握手都要3秒多。抓包一看，证书链太长，再加上OCSP查询超时。后来改成会话复用（Session Ticket），握手时间降到了200毫秒。审计模块里一定要记录握手耗时和会话复用标志，这是排查性能瓶颈的关键线索。
1.3 加密原理
TLS加密实际上是「三合一」：身份认证（证书）、密钥协商（DH/ECDHE）、对称加密（AES-GCM）。
- 非对称加密（RSA/ECC）：用于证书签名和密钥交换。我习惯在审计日志里记录证书指纹和公钥算法，后面做异常检测时特别有用。
- 对称加密（AES、CHACHA20）：真正加密数据。GCM模式自带完整性校验，比旧的CBC好多了。
- 哈希（SHA-256、SHA-384）：用于消息认证码和PRF。
TLS 1.3砍掉了很多老算法，只保留了AEAD。我个人觉得这是好事——少一个选项，少一个坑。
🔐 关键点：审计配置里一定要关注密码套件的选用。比如TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256是目前最安全的组合之一，而TLS_RSA_WITH_AES_128_CBC_SHA就存在Lucky13攻击风险。建议在DSPM规则中把不安全的套件打上高风险标签。
1.4 常见攻击方式
做审计不可能不知道攻击手法。我把最常见的几类列出来：
| 攻击名称 | 目标版本 | 原理简述 | 审计检测点 |
|---|---|---|---|
| POODLE | SSL 3.0 | 利用CBC填充字节预测明文 | 检查是否允许SSL 3.0 |
| BEAST | TLS 1.0 | 利用CBC初始化向量可预测性 | 检查是否使用TLS 1.0 + CBC |
| Heartbleed | TLS 1.0/1.1 | OpenSSL缓冲区越界读 | 检查OpenSSL版本号 |
| Lucky13 | TLS 1.0~1.2 | CBC填充区分攻击 | 检查是否使用CBC模式套件 |
| Downgrade | 所有版本 | 强制客户端降级到弱版本 | 检查版本协商日志 |
⚠️ 曾经遇到过的真实案例：有次渗透测试，对方明明部署了TLS 1.2，但握手时客户端主动发了一个TLS 1.0的ClientHello，服务端竟然也接受了。原因是服务端没做版本下限限制，降级攻击直接成功。咱们的DSPM审计规则应该把「不强制最高版本」也列为中危告警。
嗯，以上就是TLS协议基础的四个核心模块。理解这些之后，咱们后面配置审计规则时才能知道该抓哪些日志字段、该告警什么异常。