Fiddler如何捕获HTTPS请求？

Question

在使用Fiddler捕获HTTPS请求时，为什么部分HTTPS流量仍显示为CONNECT隧道而无法解密？即使已勾选“Decrypt HTTPS traffic”并安装Fiddler根证书，某些应用或浏览器仍拒绝信任Fiddler的中间人解密行为。这通常与系统或应用级别的证书校验机制有关，如Chrome使用了增强的证书绑定（Certificate Pinning），或移动端App集成了SSL Pinning技术。此外，Windows Defender等安全组件也可能拦截未受信任的证书。如何排查并解决此类HTTPS解密失败问题，确保Fiddler能完整捕获所有HTTPS明文请求？

Answer 1

一、HTTPS流量捕获原理与Fiddler工作机制

Fiddler作为一款HTTP/HTTPS调试代理工具，其核心功能是通过在本地监听8888端口（默认）充当中间人代理（Man-in-the-Middle, MITM），从而拦截并解密客户端与服务器之间的通信。当启用“Decrypt HTTPS traffic”选项时，Fiddler会生成一个动态的根证书（FiddlerRoot Certificate），并用该证书签发针对目标域名的临时SSL证书，实现对HTTPS流量的解密。

然而，在实际使用中，部分HTTPS请求仅显示为CONNECT隧道，无法查看明文内容。这表明Fiddler未能成功解密该连接，原因通常在于终端应用或系统层面拒绝信任Fiddler签发的证书。

1.1 CONNECT隧道的本质

• HTTP协议中的CONNECT方法用于建立到目标服务器的隧道，常用于HTTPS通信。
• 当客户端发起HTTPS请求时，首先通过CONNECT host:port请求Fiddler建立隧道。
• 若Fiddler能成功解密，则后续流量将被解包并展示为可读的HTTP(S)会话；否则仅显示隧道状态，内容不可见。

二、常见导致HTTPS解密失败的原因分类

类别	具体原因	典型场景
证书信任问题	未正确安装或信任Fiddler根证书	Windows/macOS未导入证书至受信根证书颁发机构
证书固定（Pinning）	应用内置公钥指纹校验	Chrome、Android/iOS App使用SSL Pinning
安全软件拦截	杀毒软件或防火墙阻止伪造证书	Windows Defender、McAfee等主动拦截
操作系统限制	现代系统增强TLS安全性策略	Windows 10+ SChannel强制验证证书链完整性
浏览器增强防护	HPKP、Expect-CT、Certificate Transparency	旧版Chrome曾支持HPKP，现多由应用层实现类似逻辑
移动设备特殊机制	User Trust Store vs System Trust Store	Android 7+仅信任系统证书库，用户安装无效

三、深度排查流程与诊断方法

1. 确认Fiddler配置正确：检查是否勾选“Decrypt HTTPS traffic”，并确保Fiddler证书已在系统级受信。
2. 验证证书安装情况：打开Fiddler → Tools → Options → HTTPS → 点击“Actions” → “Export Root Certificate to Desktop”，然后手动导入至系统的“受信任的根证书颁发机构”存储区。
3. 测试基础浏览器行为：使用IE或Edge（非Chromium内核）访问https://www.baidu.com，观察是否可解密，以排除通用配置错误。
4. 分析CONNECT会话详情：选中仅显示CONNECT的条目，在Inspectors中查看Request Headers和Response状态码（如443响应表示隧道建立成功但无解密）。
5. 启用Fiddler日志输出：进入Rules → Customize Rules，添加日志打印语句，监控OnBeforeRequest和OnBeforeResponse事件中的TLS握手异常。
6. 使用命令行工具辅助判断：运行certutil -store -v "Root"（Windows）查找是否存在"FiddlerRoot"证书且标志为受信。
7. 检查组策略或MDM策略：企业环境中可能存在禁止用户证书注入的安全策略，影响Fiddler证书信任。
8. 对比不同网络环境：尝试关闭Wi-Fi安全网关或代理自动配置脚本（PAC），避免上游代理干扰。

四、典型场景解决方案详解

4.1 浏览器级证书绑定绕过（以Chrome为例）

Chrome采用多种机制防止中间人攻击，包括：

• 预加载HSTS（HTTP Strict Transport Security）站点列表
• 历史遗留的HPKP（HTTP Public Key Pinning）机制（已弃用）
• 当前广泛使用的Certificate Transparency 和 Dynamic Trust Management

解决方式：

# 启动Chrome时禁用证书固定检查（仅用于调试）
chrome.exe --ignore-certificate-errors --disable-features=CertRevocationCheckingEnabled
# 或更彻底地绕过安全警告
chrome.exe --unsafely-treat-insecure-origin-as-secure=https://target.com --user-data-dir=C:\Temp\ChromeDevSession

4.2 移动App SSL Pinning应对策略

许多原生App（如银行类、社交类）集成OkHttp + CertificatePinner、或iOS的NSAppTransportSecurity配置，强制校验服务端证书指纹。

常用逆向手段包括：

1. 使用Xposed框架（Android）配合JustTrustMe模块禁用SSL Pinning
2. 利用Frida脚本Hook关键API（如X509TrustManager.checkServerTrusted）
3. 重打包APK并修改Smali代码移除pinner初始化逻辑
4. 使用Magisk模块在系统层注入信任证书

五、高级调试技巧与自动化检测流程图

以下Mermaid流程图展示了从发现CONNECT隧道到最终定位问题根源的完整诊断路径：

graph TD
    A[捕获到CONNECT隧道] --> B{是否所有HTTPS均无法解密?}
    B -->|是| C[检查Fiddler根证书是否安装]
    B -->|否| D[特定App或域名失败?]
    C --> E[导入FiddlerRoot证书至受信根存储]
    E --> F[重启Fiddler并重试]
    D --> G[判断目标应用类型]
    G --> H[Web浏览器?]
    G --> I[原生App?]
    H --> J[尝试使用--ignore-certificate-errors启动参数]
    I --> K[检查是否启用SSL Pinning]
    K --> L[使用Frida/Xposed进行Hook]
    L --> M[成功解密流量]
    F --> N[仍失败?]
    N --> O[检查杀毒软件拦截记录]
    O --> P[临时关闭Windows Defender实时保护]
    P --> Q[重新测试]

六、长期维护建议与最佳实践

• 定期更新Fiddler版本：新版支持更强的TLS 1.3兼容性及更好的证书管理界面。
• 区分开发与生产环境：切勿在正式环境中启用MITM代理，防止敏感信息泄露。
• 构建专用调试设备：为移动端抓包准备刷机后的测试手机，预装Magisk、LSPosed等框架。
• 结合其他工具协同分析：搭配Wireshark进行底层TCP/TLS层比对，确认Fiddler是否收到完整ClientHello消息。
• 编写自定义FiddlerScript：扩展OnBeforeResponse事件，自动标记疑似Pinning行为的响应特征。
• 关注RFC标准演进：了解如TLS Encrypted Client Hello (ECH) 对未来抓包技术的影响。