Fiddler 能修改 HTTPS 流量的原理
这是一个**中间人攻击（Man-in-the-Middle, MITM）**的合法应用。Fiddler 通过以下机制实现：
核心原理：SSL/TLS 代理伪造
正常 HTTPS:
客户端 ──────────────────────────── 服务器
加密通信（只有两端能解密）
安装 Fiddler 后:
客户端 ←→ Fiddler ←→ 服务器
↑ ↑
假证书 真证书
(客户端信任) (Fiddler解密)Fiddler 实际上建立了两条独立的 TLS 连接：
- 客户端 → Fiddler：使用 Fiddler 自己生成的伪造证书加密
- Fiddler → 服务器：使用服务器的真实证书加密
关键步骤
① 安装根证书（Root CA）
- Fiddler 安装时会在系统证书库植入自己的根证书（Root CA）
- 操作系统和浏览器信任这个根 CA，所以 Fiddler 动态伪造任何域名的证书都不会报警
② 动态生成证书
- 当你访问
https://api.example.com时 - Fiddler 实时生成一张
api.example.com的假证书 - 用自己的根 CA 签名 → 客户端验证通过
③ 中间解密再转发
客户端发出请求
↓
Fiddler 用假证书解密 → 读取/修改明文数据
↓
Fiddler 用真证书重新加密 → 转发给服务器
↓
服务器响应 → Fiddler 解密 → 读取/修改 → 重新加密返回客户端为什么平时 MITM 行不通？
| 条件 | 普通攻击者 | Fiddler |
|---|---|---|
| 根证书是否被信任 | ❌ 没有 | ✅ 手动安装到系统 |
| 是否控制网络流量 | 需要入侵 | ✅ 配置系统代理 |
| 结果 | 浏览器报证书错误 | 正常通过 |
安全机制的本质是：浏览器信任谁签的证书。Fiddler 能绕过，是因为你主动授权了它的根证书。
防御机制（对抗 Fiddler 抓包）
部分应用会使用额外防护：
- Certificate Pinning（证书固定）：App 内置服务器的真实证书指纹，不接受任何其他证书，即使是系统信任的 CA 签发的也不行
- HPKP：HTTP 层面的公钥固定（已较少用）
这就是为什么抓取某些 App 的 HTTPS 流量需要额外 hook 或绕过 pinning。
总结一句话：Fiddler 能改 HTTPS 数据，是因为你主动信任了它的根证书，让它合法地扮演"中间人"角色。