证书固定 仍会拦住什么

在 iOS 上，解密取决于 Busymate 描述文件是否已安装并在「设置」中获得完全信任——之后手机上的每个应用都会信任该应用出示的证书，做了固定的应用除外。Android 有两个信任库：用户库，自 Android 7.0 起只有明确选择信任的应用才会采纳；系统库，所有应用都采纳，但只有 root 过的设备才能写入。桌面代理则依赖客户端机器或浏览器对其生成的证书机构的信任。

证书固定凌驾于这三者之上。做了固定的应用无论替代证书来自哪个库都会拒绝，所以把证书移到更强的库永远对固定主机无效。它只对那些拒绝用户库的应用有效。

你没有列入解密清单的主机会显示闭合的锁，只有主机名和请求计数——这是设计如此，不是固定。固定主机看起来不一样：它在你的列表里，解密已被尝试，连接却失败了，或者应用重试后放弃。仪表盘信息流的检查筛选器有三档——仅已解密、仅加密、仅 SSL 固定——最后一档正好把这些行单独筛出来。

另一个迹象是行为：主机一被解密，应用对该主机就停止工作；你把主机从列表移除，它立刻又能用了。如果两者都成立，你就找到了一个固定连接。

iOS 应用在系统层面抓包，覆盖 Wi-Fi 和蜂窝网络，并解密你列出的主机。面对做了固定的应用，它仍会记录每一个连接——主机、时间、请求的数量和大小、当时生效的连接模式——但无法产出头部或正文，也没有任何开关能改变这一点。打开 MITM All Hosts 会解密所有未固定的主机；对固定主机它除了把它弄坏之外什么也做不了。

实用做法是把固定主机从列表中移除，让应用继续正常工作，保留应用的其他主机，然后读取未固定端点透露的信息。很多应用只固定认证或支付主机，其余都是开放的。

在未 root 的 Android 手机上，应用生成的证书存在用户库中，因此只有你自己的调试版本和其他选择信任的客户端能被解密；其他所有应用只记录为元数据。在 root 过的设备上，证书可以装进系统库，HTTPS 便可在系统范围内解密——每个应用自己的证书固定除外。手机集群正是为此让它的 Android 设备运行在这一 root 级别。

所以 root 把一类不透明的应用——那些只是忽略用户库的应用——变成可读的，而对固定类应用毫无影响。Busymate 从不声称在未 root 设备上能系统级解密，也从不声称在 root 设备上能击败证书固定。

桌面代理与证书固定的关系和手机应用一样：做了固定的客户端拒绝它生成的证书，连接失败。它还有一份短名单，无论你的 SSL 代理设置怎么写都绝不拦截——Apple 自己的 PKI 和吊销端点、Apple 证书链使用的证书状态响应器，以及 Busymate 自己的后端——因为拦截它们会破坏设备或仪表盘自己的实时连接。这些以原始隧道方式通过，这是有意为之，不是配置错误。

有一条抓包路径完全不受证书固定影响。命令行连接器启动一个 Chrome 实例，通过 DevTools Protocol 在 TLS 的浏览器一侧读取它的流量。Chrome 与服务器之间的加密连接从未被触碰——没有替代证书可拒绝，没有东西要安装，也没有任何东西可供证书固定检测。那些代理无法打开其固定证书的服务商的登录流程，会被端到端完整记录，包括重定向和令牌。

代价是范围：它覆盖的是在那个 Chrome 里运行的内容，而不是原生应用。如果你关心的流程有网页版，这条路径能完整地看到它。

元数据并非一无是处。你仍能看到应用何时与固定主机通信、频率多高、交换数据多大、耗时多长，并把这些与周围已解密的调用关联起来。拦截规则在加密主机上仍能按主机级别匹配——路径不可见，但你可以让应用表现得像该端点不可达，这往往正是你想测试的失败模式。暂停功能能让该主机完全绕过代理，使应用照常工作，同时你检查其他一切。

而且你采取的每一步操作都在审计日志中，所以一次研究会话会留下记录：什么被解密了、什么被拦截了、什么被放过了。