6.1 TLS 解密实战：密钥日志的正确用法

6.1 TLS 解密实战：密钥日志的正确用法

4.3 节展示了 TLS 信封的明文层，本节打开信封里的内容。方法只有一条正道：让受控端在握手时导出会话密钥。本节覆盖密钥日志的配置、Wireshark 与 tshark 两侧的加载、解密失败的三大排查，以及解密之后分析工作的完整走法。这是前后端联调、协议研究、漏洞复现场景的标配能力。

第一步：让客户端交出钥匙

主流浏览器与多数 TLS 库都内置了密钥导出开关——同一个环境变量，到处通用：

# Linux 与 macOS
$ export SSLKEYLOGFILE=$HOME/tlskeys.log

# Windows PowerShell
PS> $env:SSLKEYLOGFILE = "$HOME\tlskeys.log"

# 然后从同一个 shell 启动浏览器（环境变量要传得进去）
$ firefox &
$ google-chrome &
​

写好的日志长这样——每行一个密钥，标签区分用途：

$ cat tlskeys.log | head -5
CLIENT_HANDSHAKE_TRAFFIC_SECRET 0a1b...（96 个十六进制字符）
SERVER_HANDSHAKE_TRAFFIC_SECRET 0a1b...
EXPORTER_SECRET c2d3...
CLIENT_TRAFFIC_SECRET_0 4e5f...
SERVER_TRAFFIC_SECRET_0 4e5f...
​

TLS 1.3 的每行带方向与序号（握手期、应用期、客户端向、服务端向），TLS 1.2 则是 RSA 或 ECDHE 开头的预主密钥行。文件是追加式的，长期使用会积累大量密钥——它本身是高敏材料，用完即删，权限收紧。

服务端场景同理：多数语言的服务端 TLS 库支持同样的钩子，把密钥写进日志；Java 系的参数名不同（密钥日志的系统属性方案），思路一致：让持有会话密钥的一端主动记录。

第二步：Wireshark 加载钥匙

GUI 一次性配置：打开首选项的 TLS 协议页，把"密钥日志文件名"指到上面的文件。此后所有打开的捕获文件，凡是握手被完整抓到的 TLS 会话都会自动解开——列表的协议列从 TLS 变成 HTTP2，详情树里多出"解密的应用数据"层。

$ tshark -r session.pcapng -o "tls.keylog_file:$HOME/tlskeys.log" \
    -Y "http2" -T fields -e http2.headers.method -e http2.headers.authority -e frame.number
GET	www.example.org	14
GET	img.example.org	21
POST	api.example.org	29
​

命令行的 -o 选项与 GUI 首选项完全等价（同一配置体系的两个入口）。解密成功的直接证据：HTTP/2 的伪头部（method、authority）从密文里浮出来了——这些字段在 4.3 节的明文层里是看不到的，HPACK 压缩头只在解密后才有意义。

第三步：解密之后怎么分析

解密不是终点，是第二解剖现场的开工。此前所有筛法原样适用，只是多了一整层应用语义：

# 解密前：只能看到信封（4.3 节的观察点）
$ tshark -r session.pcapng -Y "tls" -T fields -e tls.record.content_type | sort | uniq -c
  412 23      <- 应用数据（密文）
   38 22      <- 握手
    2 21      <- 警报

# 解密后：信纸摊开，HTTP/2 的全部字段可用
$ tshark -r session.pcapng -o "tls.keylog_file:$HOME/tlskeys.log" \
    -Y "http2.headers.status" -T fields -e http2.headers.status -e frame.time_delta
200	0.038
200	0.041
504	30.001   <- 网关超时在应用层现形，与 4.3 节明文案的判定法接轨
​

联调场景的标准走法：先在明文层确认握手健康（版本、套件、轮数），再进解密层看请求响应配对与状态码分布——等于把 4.3 节的 HTTP 解剖能力平移进了加密会话。

正道之外的路都不通（或不必）

有人会问：拿到服务端私钥能不能解？TLS 1.3 与启用前向保密的 TLS 1.2 里不能——私钥只用于身份验证，不参与会话密钥的最终确定，这正是前向保密的设计目标。中间人代理（本地起代理、客户端信任代理证书）是另一条常见路线，属于"改变拓扑"而非"解密"，适合调试自己的客户端，不适合分析别人的既有流量，且涉及证书信任的改动要谨慎回滚。对加密流量的合规分析姿势，本质仍是 6.2 节的边界问题。

⚠️ 密钥日志文件在，等于门钥匙在。共享屏幕、打包目录、提交代码仓库，三个场景都可能顺手把密钥带出去。给这个文件设好权限，并把它列进"用完即删"清单。

联调实录：一次接口报错的解密勘验

完整走一遍。案情：测试环境某接口偶发 503，日志语焉不详，客户端走 HTTPS。

# 第 1 步：确认环境——测试客户端是 curl（多数构建支持密钥导出环境变量）
$ export SSLKEYLOGFILE=$HOME/keys.log
$ curl -v https://api.test.local/v2/orders > /dev/null
* TLSv1.3 (IN), TLS handshake, Finished (20):    <- 一次健康握手

# 第 2 步：在采集文件上加载钥匙，还原应用语义
$ tshark -r api503.pcapng -o "tls.keylog_file:$HOME/keys.log" \
    -Y "http2.headers.status" -T fields -e frame.number -e http2.headers.status -e frame.time_delta
18	200	0.041
24	503	0.038      <- 503 响应 38 毫秒就回来了：不是超时，是被立即拒绝

# 第 3 步：看 503 响应体里的错误详情（解密后载荷可读）
$ tshark -r api503.pcapng -o "tls.keylog_file:$HOME/keys.log" \
    -Y "http2.data.data && tcp.srcport==443" -T fields -e http2.data.data -c 1
7b226572726f72223a22757073747265616d2074696d656f7574227c...
# 十六进制转文本：{"error":"upstream timeout"...}
​

三层递进：明文层确认握手健康，解密层定位 503 与响应速度（毫秒级返回说明是主动拒绝），载荷层读到根因字符串（上游超时）。没有解密，后两层永远不可见——这就是这把钥匙在联调场景的分量。

客户端钥匙导出速查

速查表的潜台词：只要有一端受你控制，就能拿到钥匙——这正是"被授权的一方的主动配合"在工程上的含义。两端都不受控（分析他人流量）时，6.2 节的边界讨论先于一切技术动作。

结案要点

• 正道一条：SSLKEYLOGFILE 环境变量导出会话密钥，GUI 首选项或 -o tls.keylog_file: 加载。
• 解密成功的标志：协议列出现 HTTP2，伪头部字段可筛。
• 失败三查：握手抓全没、密钥同期没、版本支持没。
• 私钥解不了现代 TLS：前向保密之下，私钥只验证身份。
• 密钥日志即门钥匙：权限收紧、用完即删、绝不入库。

能看懂加密流量之后，下一节划红线——哪些流量不该看、看到的材料怎么管。