同事把一个抓好的包发过来问我这 Wireshark 打开怎么全是密文。这种时候先别怀疑文件坏了——十有八九是密钥没带上。而给 Wireshark 喂密钥这件事就绕不开 SSLKEYLOGFILE 这个环境变量。先说这套思路让程序自己把 TLS 握手协商出来的会话密钥写进一个文本文件再把 Wireshark 指过去读那个文件。# macOS / Linux设好变量后从终端直接启动浏览器 export SSLKEYLOGFILE/tmp/sslkey.log /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome # WindowsPowerShell $env:SSLKEYLOGFILE C:\temp\sslkey.log C:\Program Files\Google\Chrome\Application\chrome.exe然后在 Wireshark 里首选项 → Protocols → TLS → (Pre)-Master-Secret log filename把上面那个文件路径填进去。之后抓到的 TLS 流量就能解成明文了。macOS 上有个小坑别用open -a Google Chrome去启动。open是把请求交给系统服务去拉那个进程环境里并没有你刚设的变量密钥文件照样不会生成。得直接从终端跑浏览器二进制。这套不复杂但它有前提而且前提还挺苛刻。一、这种方式什么时候会失败三个卡点碰上任意一个基本就没辙了。第一程序得自己支持这个机制。SSLKEYLOGFILE 不是 TLS 协议的一部分它是一个约定——程序内部得写了把密钥写出去的那段逻辑才会认这个环境变量。Chrome、Firefox 这一系背后是 NSS / OpenSSL 这类密码库是支持的所以拿它解浏览器流量最顺。可换成一个自己实现网络栈的桌面客户端、或者用了别的 TLS 实现的程序变量设了也白设文件压根不会生成啊。第二事后补不回来。密钥是握手那一刻产生的程序当时没导出那个文件就永远不会有。所以如果手上的包是同事昨天抓的、或者来路是一台你没法重跑的机器这条路直接出局——这也是它最容易让人白忙一场的地方。第三环境变量很容易没生效。在终端里设好了变量程序却是从桌面图标点起来的这是最常见的翻车方式在 Windows 上尤其多——我自己就干过不止一次设完变量顺手去点图标然后对着一个空文件发愣。还有些场景跑在别的用户下的服务、容器里的进程根本继承不到你设的变量。所以设完之后先去确认那个密钥文件真的生成了、里面有内容比什么都强。SSLKEYLOGFILE 是把解密钥匙交给你但这把钥匙得程序愿意给。二、另一条思路让解密方自己参加握手抓包工具走的普遍是另一条路在握手阶段就以对端身份参与进去——它跟客户端完成一次真正的 TLS 握手只不过是冒充了你要访问的那台服务器。既然是握手的当事一方会话密钥就是它自己算出来的也就不需要任何人给它喂文件。装个证书就能直接看明文原因就在这儿不是它破解了密钥是密钥本来就握在它手里。这条路的代价同样明确客户端得信任那张证书。而麻烦基本都出在信任这两个字上——系统信任库里装上还不够因为 Java、Python 这类程序读的是自己的信任库压根不看系统那张再往上还有证书绑定Pinning程序直接拒绝握手连报错都懒得给。这几道坎以前的文章里拆过这儿就跳过去吧。在TraceEagle里这条路的几个卡点被补过证书体系是内置的装一次持续解密系统证书一键全覆盖连那些读自己信任库的程序也能覆盖到碰上做了证书绑定的应用可以一键解除它对这个会话的校验。再往后还有从程序内部直接取明文的抓法那就是完全不同的一条路线了。三、两种方式怎么挑判断标准其实就一条你能不能控制流量的生成过程。目标是自己能招呼的浏览器、或者支持导出密钥的程序——密钥文件这条路最省事不用装证书、不用改代理配置抓完的包随时能解。目标是个 App、桌面客户端、命令行工具尤其源码不在你手上的第三方程序——老老实实走中间人那套让抓包工具替你参加握手。流量早就抓完了手上只剩一个包——先看它导出时有没有带上密钥。带了密钥的 pcapng 还能解光秃秃的 pcap 就真没救了。三条里最容易被忽略的是第三条很多人拿到包第一反应是去 Wireshark 里翻设置折腾半天其实问题出在导出那一步。下次再收到别人发来的包先看一眼导出的时候有没有把密钥带上吧。四、几个常问的SSLKEYLOGFILE 对 TLS 1.3 还有效吗机制上没什么区别只要程序支持导出、导出的确实是这次会话的密钥就行。真正的分界线还是程序支不支持跟 TLS 版本关系不大。变量设了、文件也生成了Wireshark 还是解不开先确认填的路径对不对、文件里是不是真有内容再对着时间看一眼——这段流量是不是在密钥产生之前就抓的。早于密钥的那些包补不回来。用抓包工具还需要我导出密钥吗不需要。它自己在握手时就拿到了。这是它和给 Wireshark 喂密钥最本质的差别也是为什么它对你目标程序的支持情况不那么挑剔。有没有不想解密的流量有而且挺常见——某些自带强校验的站点解密反而会引来一堆报错得不偿失。TraceEagle里可以按域名分流白名单只解密你指定的域名、其余放行放行名单让特定站点原样透传、不去解密阻断名单则干脆拦掉。五、和常见工具比一比Wireshark 自己也能解 TLS靠的就是密钥文件这条路——它在协议层看得最深代价是先得把密钥弄到手。Charles、Proxyman、mitmproxy 走的是中间人那套装好证书就行不需要密钥文件长处在于对 HTTP 结构化内容更友好。现实里最常见的组合是反过来的拿抓包工具看接口内容顺手把密钥给 Wireshark 备着做逐包深挖。两者本来也不冲突嘛。密钥文件和中间人两种方式差别不在谁更强在密钥从哪来一个是让程序主动交出来一个是解密方自己算出来。搞清楚区别下次再对着满屏密文起码知道该往哪个方向使劲了——总比在 Wireshark 的设置面板里翻半天强吧。