TLS协议简介与审计需求概述

说到TLS，很多人第一反应是“加密”。其实不光是加密，它是个组合拳。我做审计时经常遇到团队只把TLS理解成“把数据包锁起来”，这是一个很危险的简化。

TLS（Transport Layer Security）的核心目标就三个：加密、完整性、身份验证。这三者的关系有点像密码箱——加密保证内容不被偷看，完整性保证内容不被调包，身份验证保证钥匙没拿错。

TLS解决了什么问题？

在TLS出现之前，网络通信是明文裸奔的。你在网上买东西填的信用卡号，经过每个路由器都是明码。我当年在金融行业做排查时，抓了个包看到客户请求里的密码字段直接是明文，项目经理脸都绿了。这就是没有TLS的后果。

TLS主要解决这三个场景的问题：

• 窃听（Eavesdropping）：中间节点可以读取通信内容
• 篡改（Tampering）：中间节点可以修改传输的数据
• 冒充（Impersonation）：客户端无法确认服务器身份

TLS握手的“骨架”

大家可能都见过TLS握手的流程图。我在这里用口语化的方式讲一遍，配合后面一张图你就能看明白。

握手开始后，客户端会发一条ClientHello，里面带上自己的“底牌”——支持的TLS版本、密码套件列表、随机数。服务端收到后挑一个组合，回ServerHello。接着发证书、做密钥交换。最后用ChangeCipherSpec告诉对方：下面我要用密码说话了。

为什么握手这么重要？因为证书验证、密码套件协商、密钥交换这三个环节直接决定了连接的安全底线。我们做审计的时候，绝大部分问题都出在这三步。

TLS的关键参数一览

这里有一个表格，是我每次做审计前都会打开对照的。你不用背，但要知道每个参数影响的是什么。

参数类别	常见参数	审计关注点
协议版本	TLS 1.2 / TLS 1.3	是否禁用TLS 1.0 / 1.1
密码套件	TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384	是否支持PFS、避免CBC模式
证书	X.509 v3, SHA-256签名	证书链完整性、吊销状态
密钥交换	ECDHE / DHE	是否完美前向保密
MAC/哈希	SHA-256 / SHA-384	是否避免MD5 / SHA-1

你注意看表格里密码套件的写法。“TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384”——这个字符串其实包含了密钥交换算法、签名算法、对称加密模式、哈希算法。我之前在一次合规审计中发现，客户配置里写着“ECDHE_RSA_WITH_AES_128_CBC_SHA256”。嗯，这里面CBC模式在2018年后已经被确认存在安全缺陷。那就是个需要整改的发现项。

为什么审计TLS？

很多团队觉得TLS只要“开了https”就行。我遇到过最夸张的一个案例：一个金融App的TLS版本还开着TLS 1.0，证书用的是1024位RSA。做渗透测试时，用现成工具几分钟就能模拟中间人攻击。你想想看，这种配置和没加密有什么区别？

审计TLS参数的目的就是：确认配置是否合规、是否安全、是否可追溯。合规性来源于标准（如PCI DSS、GDPR、等保2.0），安全性来源于当前攻击面，可追溯性来源于日志记录。

从协议到日志的“连接线”

好了，我们把前面讲的内容串一下。TLS协议本身提供安全通信，但审计人员需要的是“证据”——连接是否建立、使用了什么参数、有没有异常中断。这就是TLS参数和审计日志映射的由来。

下面这个图展示了整体逻辑：TLS层产生的参数，经过业务系统处理，最后进入日志系统。每一个环节都有可控和可查的地方。

你看这个图，从左到右是一个完整的数据流：TLS层产生的参数、握手状态、证书信息，这些数据经过业务系统的封装，进入日志采集器，最后落到审计存储与分析系统里。每个节点之间的箭头都在告诉我们：少了哪一步，都无法真正满足合规要求。