NetWatch解密你的HTTPS流量：SSLKEYLOGFILE配置TLS 1.3/1.2与QUIC解密完整教程
【免费下载链接】netwatchReal-time network diagnostics in your terminal. One command, zero config, instant visibility.项目地址: https://gitcode.com/gh_mirrors/netwatc/netwatch
NetWatch 是一款终端内的实时网络诊断工具，它不仅能抓包，还能配合SSLKEYLOGFILE环境变量解密 TLS 1.3、TLS 1.2 与 QUIC（HTTP/3）的应用层明文，让你在自己的终端里直接读到 HTTPS 请求和响应。本文是一份面向新手的完整教程：从零配置密钥日志文件，到在 Packets 面板中筛选、查看解密后的 HTTP 流量。
一、原理解析：SSLKEYLOGFILE 是怎么让 HTTPS 现形的
HTTPS 流量本身是加密的，被动抓包工具通常只能看到乱码。SSLKEYLOGFILE是 OpenSSL、NSS 等主流 TLS 库支持的调试机制：
- 客户端进程（浏览器、curl、Node 等）启动时指定一个文件路径；
- 每次 TLS 握手成功后，库会把本次会话的密钥材料（keylog 记录）追加写入该文件；
- NetWatch 在后台持续监听（tail）这个文件，用其中的密钥对抓到的加密记录做 AEAD 解密，还原出明文 HTTP。
这与 Wireshark 的解密方式完全一致。需要强调：它只能解密你自己控制的、主动导出密钥的连接，是纯只读的调试功能，无法用于解密第三方或恶意流量。
二、准备工作：安装与权限
- 抓取流量需要 pcap 权限：Linux 下运行
sudo netwatch或把用户加入抓包组；macOS 上加入access_bpf组或提权运行。 - 客户端必须是OpenSSL 系的 TLS 实现（curl、Chrome、Firefox、Node 均可）；macOS 自带的 LibreSSL 系工具不写 keylog，例如 Homebrew 安装的
python3才支持。 - 一条经验法则：先启动 NetWatch 抓包，再发起请求。如果 ClientHello（握手请求）发生在抓包之前，该连接将永远无法解密。
三、最快配置方法：设置 tls_keylog_path
NetWatch 零配置即可运行，但解密需要告诉它 keylog 文件的位置。编辑配置文件（Linux 为~/.config/netwatch/config.toml），或先运行netwatch --generate-config生成模板，然后加入一行：
tls_keylog_path = "/tmp/sslkeylog.txt"该选项默认值为空，即不设置就完全不解密——它是纯配置项，TUI 设置界面中没有对应行（详见 docs/REFERENCE.md 的 TLS 1.3 / 1.2 decryption 小节）。
四、TLS 1.3 解密实战：用 curl 读出 HTTPS 明文
三步完成：
- 启动 NetWatch 开始抓包（默认进入 Packets 标签页）；
- 在另一个终端带环境变量发起请求：
SSLKEYLOGFILE=/tmp/sslkeylog.txt curl https://example.com- 回到 NetWatch，被解密的记录会以绿色加粗直接内联渲染明文；输入
/打开过滤栏，键入decrypted:true即可只看解密流量，contains "hello"甚至能全文搜索解密后的明文。
支持全部三个 TLS 1.3 套件：TLS_AES_128_GCM_SHA256、TLS_AES_256_GCM_SHA384、TLS_CHACHA20_POLY1305_SHA256，并且能跟随 TLS 1.3 KeyUpdate 重密钥化继续解密不断流。
五、TLS 1.2 解密：同样支持，注意仅 AEAD 套件
TLS 1.2 走CLIENT_RANDOM类型的 keylog 记录：NetWatch 从 keylog 取出 48 字节主密钥，再从抓到的 ServerHello 中读取server_random，按 RFC 5246 §5 的 PRF 推导出密钥块，逐条解密应用数据记录。
- ✅ 支持：ECDHE 的 AES-128/256-GCM 与 ChaCha20-Poly1305 套件
- ❌ 不支持：传统 CBC（mac-then-encrypt）套件，这类流量会保持加密状态
一条 keylog 缺失永远不会弄坏抓包——最坏情况只是该记录保持不可见（opaque）。官方还附带了端到端验证脚本 scripts/verify-tls12-decrypt.sh 和测试 harness examples/tls12_decrypt_live.rs，覆盖所有支持套件加一个"必须解不出来"的 CBC 负向对照。
六、QUIC（HTTP/3）解密：连 443 端口上的 UDP 也能读
现代浏览器（如 Chrome）大量走 QUIC over UDP，这是很多工具的盲区。NetWatch 从 v0.25.0 起支持 QUIC 1-RTT 短包头解密：
- 从 keylog 的
*_TRAFFIC_SECRET_0记录推导 1-RTT 密钥（RFC 9001 §5）； - 短包头在网络上不携带套件与 CID 长度，首个报文用 AEAD 认证作"预言机"暴力试探后缓存，之后每包直接解密；
- 解密后的 HTTP/3 响应体会自动解压缩（gzip/deflate/brotli），跨包的大响应也能重组还原（实现见 src/dpi/quic.rs 与 src/dpi/http3.rs）。
浏览器场景示例：
SSLKEYLOGFILE=/tmp/sslkeylog.txt google-chrome # Chrome / Firefox / Node 同理打开任意 HTTPS 站点，Packets 面板中对应流即显示解密后的 1-RTT 载荷（标记为 "QUIC 1-RTT decrypted"）。
七、查看与导出：像看明文 HTTP 一样看流量
| 操作 | 效果 |
|---|---|
/+decrypted:true | 只显示成功解密的报文 |
s（跟随流） | 按请求/响应顺序展示解密后的完整会话，头部带 🔓 标记 |
y | 把完整解密载荷复制到剪贴板 |
E | 导出 PCAP |
协议细节（Protocol Detail）与载荷内容（Payload Content）面板会同时展示还原出的明文，方便新手理解每一层封装。
八、常见问题（FAQ）
- 为什么解密不出来？优先检查：是否先抓包后请求、keylog 路径两边是否一致、客户端是否 OpenSSL 系、TLS 1.2 是否 CBC 套件。
- keylog 文件会无限增长吗？会，每条会话追加一行，定期清理
/tmp/sslkeylog.txt即可。 - 能解密别人的 HTTPS 吗？不能，也不应尝试——该机制设计上只服务于调试自己控制的应用。
小结
借助SSLKEYLOGFILE+tls_keylog_path，NetWatch 让你在终端里获得 Wireshark 级的 HTTPS 解密能力：TLS 1.3 全套件、TLS 1.2 AEAD、QUIC 1-RTT 一网打尽，且 keylog 逻辑（src/dpi/tls_decrypt.rs）完全复用 Wireshark 验证过的机制，稳定可靠。更多配置项与过滤语法请参考 docs/REFERENCE.md 与 docs/WIKI.md。
【免费下载链接】netwatchReal-time network diagnostics in your terminal. One command, zero config, instant visibility.项目地址: https://gitcode.com/gh_mirrors/netwatc/netwatch
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
