很多人在抓包时候第一次意识到 SSL 证书认证是一堵墙

证书装了、代理配了、Wi-Fi 也确认走代理，但 iOS App 就是完全没请求。
这时候就不用浪费时间继续检查证书是否勾选“完全信任”。

问题并不在证书，而在校验位置

iOS 抓包绕不过 SSL，核心原因通常只有一个证书校验不再交给系统处理。

一旦 App 在代码里做了这些事：

  • 内置服务端证书或公钥
  • 校验 TLS 握手中的证书指纹
  • 要求客户端证书参与握手

系统信任链的作用就被弱化，甚至完全失效。
这也是为什么代理抓包工具在这些 App 上看起来没问题，但什么都抓不到。

我一般不会直接想怎么绕过，而是直接换抓包

在实际工程中，“绕过 SSL 认证”并不总是第一步。
我更习惯先问去想，有没有不依赖系统证书的抓包方式？

这一步，决定了后续是否还要折腾证书、Hook 或反编译。

代理抓包还能做什么？不要一开始就放弃

即便 App 开启了 SSL 校验，代理抓包并非完全没用。

我通常会用 Charles 或系统代理模式做两件事：

  • 验证 App 是否还会发起网络连接
  • 观察 DNS、SNI、连接失败的时机

如果 TLS 连接在握手阶段直接失败，那就说明校验发生在非常早的位置，继续在代理模式上纠结意义不大。

切换到 HTTPS 暴力抓包，是我绕过 SSL 的常用方式

当确认代理模式行不通后，我会使用 抓包大师 的 HTTPS 暴力抓包 功能。

这个模式的核心差异点在于：

  • 不依赖系统代理
  • 不要求在 iOS 上信任抓包证书
  • 请求在更贴近 App 的执行路径中被捕获

也正因为这一点，即使 App 做了 SSL 证书校验，数据依然有机会被截获。

实际操作中，我会这样启动暴力抓包

流程不复杂，但顺序很重要：

  • 用 USB 连接 iPhone，保持解锁和亮屏
  • 第一次连接时在手机上点击“信任此电脑”
  • 按提示安装 iOS 驱动并重启抓包大师
  • 在手机上安装描述文件
  • 如果是较新的系统版本，根据提示开启开发者模式

这些准备完成后，在设备列表中选中 iOS 设备，确认左下角的“高级管理服务”已经正常启动，再进入 HTTPS 暴力抓包界面。

抓之前，我一定会先做 App 级筛选

这是很多人忽略的一步。

在暴力抓包界面中，我会先点「选择 App」，只勾选目标应用。
这样做的好处很直接：

  • 系统流量不会淹没目标请求
  • 更容易判断哪些请求是 App 主动发出的

在调试 SSL 校验相关问题时，减少干扰比“抓得多”更重要。

能抓到 ≠ 一定能看全，这是绕过 SSL 的真实边界

即使成功绕过 SSL 校验，抓包结果仍然受一个条件限制：

App 是否使用 iOS 开发证书签名。

事实上：

  • 自签或重签 App：请求体和响应体可以正常查看
  • App Store 原包或系统 App：通常只能看到 URL 和 Header

这不是工具问题，而是 iOS 对未签名代码的天然保护。
https 暴力抓包

当 Body 看不到时，我通常会这样继续排查

即便只有 Header，我仍然会关注：

  • 是否命中了正确的接口
  • Header 中是否携带业务参数或状态标识
  • 请求是否重复、重试、失败

这些信息在分析 SSL 校验失败、接口异常时，往往已经足够定位问题。

真正需要完整数据时，才考虑重签名

只有在以下情况下，我才会继续往下走：

  • 必须确认请求体参数
  • 需要验证加密前的数据结构

这时，我会准备一个已脱壳的 IPA，用开发证书重新签名，再配合 HTTPS 暴力抓包重新抓取。

多工具并行，而不是“只靠绕过”

在 SSL 证书认证场景下，我常用的组合包括：

  • 抓包大师 HTTPS 暴力抓包：获取真实请求
  • 数据流抓包：确认连接行为和流量方向
  • 代理抓包工具：辅助判断 TLS 阶段失败位置

每个工具解决的问题不同，把它们放在一起，反而更省时间。

一些容易被忽略的事实

  • 不是所有 SSL 校验都“值得绕”
  • 能看到请求，不代表可以随意修改
  • 安全机制越多，抓包的边界就越清晰

理解这些限制，反而能减少很多无效尝试

参考链接：https://www.sniffmaster.net/tutorial/zh/2/2.html