Fiddler抓包显示HTTPS请求全为带锁图标？

Question

问题：使用Fiddler抓取HTTPS请求时，所有会话均显示带锁图标（Locked），无法查看明文内容，提示“Tunnel to”或直接加密传输。即使已安装Fiddler根证书并勾选“Decrypt HTTPS traffic”，仍无法解密部分或全部HTTPS流量。此现象常见于Windows 10/11系统中启用了TLS 1.3、应用程序使用了证书绑定（Certificate Pinning）或系统代理设置未正确应用的场景。如何排查并解决Fiddler无法解密HTTPS流量导致全为带锁图标的问题？

Answer 1

深入排查Fiddler无法解密HTTPS流量导致全为带锁图标的问题

1. 现象描述与初步诊断

在使用Fiddler抓取HTTPS请求时，若所有会话均显示带锁图标（Locked），提示“Tunnel to”或直接加密传输，说明Fiddler未能成功解密TLS流量。即使已安装Fiddler根证书并启用“Decrypt HTTPS traffic”选项，仍可能因多种原因导致解密失败。

• 现象：会话列表中大量出现 Tunnel to www.example.com:443
• 表现：无法查看Request/Response的明文内容
• 常见系统环境：Windows 10/11 + .NET Framework 4.7+
• 关键设置项缺失可能导致此问题

2. 基础配置检查清单

检查项	正确状态	操作路径
启用HTTPS解密	勾选	Fiddler → Tools → Options → HTTPS → Decrypt HTTPS traffic
信任Fiddler根证书	已安装至“受信任的根证书颁发机构”	Actions → Trust Root Certificate
系统代理设置	自动配置为Fiddler监听端口（默认8888）	系统网络设置或Fiddler AutoResponder
Fiddler监听端口	未被占用且允许通过防火墙	Tools → Options → Connections

3. TLS版本兼容性问题分析

自Windows 10开始，操作系统默认启用TLS 1.3，而早期版本Fiddler（如v4.x）基于.NET Framework实现，不支持解密TLS 1.3流量。这会导致即使代理生效，也无法解密现代浏览器发起的连接。

// 检查当前系统启用的TLS协议
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

可禁用TLS 1.3临时测试（仅用于调试）：
- 创建子项：TLS 1.3\Client\
- 新建DWORD：DisabledByDefault = 1
- 新建DWORD：Enabled = 0
    

建议升级至Fiddler Classic v5.0+ 或 Fiddler Everywhere，以获得对TLS 1.3的部分支持能力。

4. 应用层证书绑定（Certificate Pinning）的影响

许多现代应用（如银行App、微信客户端、Android/iOS原生应用）采用证书固定技术，验证服务器证书是否匹配预置指纹，绕过系统证书链校验机制。此类应用拒绝接受Fiddler伪造的中间人证书，导致连接中断或继续加密传输。

1. iOS平台常用TrustKit框架实现Pin
2. Android可通过网络安全配置文件定义Pinning策略
3. 桌面应用如Chrome扩展、Electron程序也可能嵌入自定义SSL逻辑

解决方案包括：

• 使用Xposed/Frida等动态Hook工具解除Pinning（需Root/Jailbreak）
• 在模拟器或测试环境中关闭安全校验
• 改用支持MITM增强模式的工具如Charles Proxy配合自定义证书部署

5. 代理未正确应用的深层排查

某些应用程序忽略系统代理设置，直接使用直连或SOCKS代理，导致Fiddler无法拦截其流量。典型场景包括：

• Node.js后端服务调用外部API
• .NET Core应用使用HttpClientHandler显式绕过代理
• Docker容器内进程不受宿主机代理影响

可通过以下方式强制代理：

// Windows命令行全局代理设置
set HTTP_PROXY=http://127.0.0.1:8888
set HTTPS_PROXY=http://127.0.0.1:8888

// Node.js示例代码中手动设置代理
const agent = new HttpsProxyAgent('http://127.0.0.1:8888');
https.get(url, { agent }, (res) => { ... });
    

6. Fiddler内部日志与事件追踪

开启Fiddler内置日志功能有助于定位具体失败环节：

1. 进入 Rules → Customize Rules...
2. 在OnBeforeRequest或OnException中添加日志输出
3. 观察输出面板中的异常信息，例如证书错误、协议不支持等

示例脚本片段：

JScript.NET
static function OnBeforeRequest(oSession: Session) {
    if (oSession.HTTPMethodIs("CONNECT") && oSession.uriContains(":443")) {
        FiddlerApplication.Log.LogString("Intercepting HTTPS tunnel: " + oSession.fullUrl);
    }
}
    

7. 替代方案与高级调试工具对比

当Fiddler受限于架构限制时，可考虑以下替代工具：

工具	支持TLS 1.3	支持移动端抓包	反Pinning能力	跨平台
Fiddler Classic	部分	弱	无	Windows为主
Fiddler Everywhere	是	较强	依赖设备配置	多平台
Charles Proxy	是	强	需手动安装证书	macOS/Win/Linux
mitmproxy	是	极强	可通过脚本干预	全平台

8. 完整排查流程图

graph TD
            A[启动Fiddler] --> B{是否勾选Decrypt HTTPS?}
            B -- 否 --> C[勾选选项]
            B -- 是 --> D{根证书是否受信任?}
            D -- 否 --> E[运行Trust Root Certificate]
            D -- 是 --> F{是否显示Tunnel to?}
            F -- 是 --> G[检查目标应用是否绕过代理]
            F -- 否 --> H[查看是否支持TLS 1.3]
            H -- 是 --> I[尝试降级TLS或更换工具]
            H -- 否 --> J[检查是否存在Certificate Pinning]
            J --> K[使用Frida/Xposed解除绑定]
            K --> L[成功捕获明文流量]

9. 移动端HTTPS抓包特殊处理

在Android 7及以上版本，应用默认不再信任用户安装的证书，必须将Fiddler证书放入系统证书存储区才能解密。对于iOS设备，则需手动信任证书并在设置中启用完全信任。

• Android：将证书复制到 /system/etc/security/cacerts/ （需root）
• iOS：设置 → 通用 → 关于本机 → 证书信任设置 → 启用对Fiddler证书的信任
• 模拟器推荐使用Genymotion或Android Studio自带模拟器，便于证书注入

此外，可结合adb命令重定向流量：

adb reverse tcp:8888 tcp:8888
# 将设备8888端口映射到PC的Fiddler监听端口
    

10. 总结性排查路线图

面对Fiddler无法解密HTTPS流量的问题，应遵循由基础到复杂的排查顺序：

1. 确认“Decrypt HTTPS traffic”已启用
2. 验证Fiddler根证书已被系统信任
3. 检查目标应用是否使用TLS 1.3且Fiddler版本支持
4. 判断是否存在证书绑定机制阻止中间人攻击
5. 分析应用是否绕过系统代理设置
6. 利用日志和调试工具定位具体失败点
7. 评估是否需切换至更强大的抓包平台
8. 针对移动设备进行专项证书部署与信任设置
9. 必要时引入动态分析工具破解安全防护
10. 建立标准化抓包环境模板以提升效率