代码审计里的前向保密：六个检查点

中间设备做解密时会终止前向保密，这是合规链路的固有代价

正着读代码容易漏，因为入口太多；反着找危险点，数据流只有那么几条。

先说结论

先列危险点，再回溯入口，最后确认校验与权限。

• 检查点一：所有外部入口是否都过统一校验
• 检查点二：危险函数是否集中封装
• 检查点三：校验是否只做一次、是否白名单
• 检查点四：权限判断是否在服务端
• 检查点五：错误信息是否泄露内部细节
• 检查点六：是否有兜底日志

检查点一：入口

ECDHE 每次握手都生成临时密钥对，会话结束即丢弃，不落到磁盘上，因此无法回溯解密。

把入口列全：HTTP 参数、请求头、上传、消息队列、定时任务的外部输入。漏一个就白审。

检查点二：危险点

TLS 1.3 只保留 DHE 与 ECDHE，前向保密从可选项变成了默认行为，配置里要显式确认。

检查点三：校验逻辑

套件顺序由服务端偏好决定时，要确认 ECDHE 套件排在 RSA 前面，否则等于没开。

看到「先替换再校验」「只在一个接口校验」这两种写法，基本可以直接标红。

这个问题的几个审计细节

实际代码里最容易漏的几处：

• 中间设备做解密时会终止前向保密，这是合规链路的固有代价

检查点四到六

中间设备做解密时会终止前向保密，这是合规链路的固有代价。

越权是审计里性价比最高的方向：少一行判断，就是一个中高危。错误信息要统一，日志要记入口摘要。

再补充几点

这几条不改变结论，但会改变你评估风险时的顺序。

• 没有前向保密时，长期私钥一旦泄露，此前录下来的全部流量都能被解密
• X25519 比 P-256 更快，常量时间实现也更简单，新系统应优先选它，旧客户端单独留一套套件
• 看到 TLS 1.2 就认为有前向保密，套件里还是 RSA
• 为兼容老客户端保留 RSA 套件，却没做例外清单
• 以为上了 TLS 1.3 就万事大吉，忽略了中间解密设备

审计的产出不是「找到几个洞」，是「知道这类洞在哪个模式里反复出现」。