部分APP无法代理抓包的原因及解决方法

引言

HTTP应用层的抓包已经成为日常工作测试与调试中的重要一环，最近接触新项目突然之间发现之前的抓包手段都不好使了，顿时模块与模块之间的前端与服务之间的交互都变成了不可见，整个人都好像被蒙住了眼睛。

其实自己也很早就发现平时使用的支付宝等APP使用Fiddler 或 Charles这类代理抓包软件默认情况下就无法抓取请求的，但使用Wireshark这类网卡抓包软件可以看到这些APP的流量，而已这些流量也表明这些APP使用的主要应用层协议仍然是HTTP（https），不过我们的代理抓包工具却失效了。如今终于在实际工作中遇到了，也不得不解决了，毕竟眼前有东西挡住会让我浑身不适。

代理抓包原理

为了弄明白为什么Fiddler 或 Charles对这些APP无效，我们有必要先了解代理抓包我原理（当然您不想了解也是完全可以的，直接看后面的实际操作就可以完成，原理分析什么的可以有兴趣随时回来看）

Fiddler 或 Charles 这类使用的代理的抓包软件与Wireshark是完全不同的（Wireshark 使用的网卡数据复制，只要是经过指定网卡都会被抓取），其只能对使用代理的应用层网络协议生效，比如常见的HTTP（https），Websocket 。

这里以HTTP为例简单说明下

客户端需要完成一次HTTP请求，通常需要先找到服务器，客户端会根据http请求中url的主机名（实际会使用host中的主角名）及其端口与目标主机建立tcp连接，建立连接后会将http报文发送给目标服务器（更多细节请参考https://tools.ietf.org/html/rfc7232）

接下来我来看下HTTP代理是如何运作的，我们启动Fiddler 或 Charles就是启动了一个HTTP代理服务器，这类工具会通知操作系统，“现在我在系统上创建了一个HTTP代理，IP为XXXXXX端口为XX。如果您使用的是linux您可以手动通知操作系统(export http_proxy=ip:port export https_proxy=$http_proxy),如果您使用的是手机等移动设备您可以在当前wifi设置处告诉系统你要使用http代理。现在我们已经告诉系统我们想要使用代理，这个时候运行在系统上的http客户端再去发送请求的时候，他就不会再去进行DNS解析，去连接目标服务器，而是直接连接系统告诉他代理所在的地址（代理的ip及端口，注意无论是http或https或其他支持代理的协议都会连接同一个端口）。然后代理服务器会与客户端建立连接，再然后代理服务器根据请求信息再去连接真正的服务器。

这里还有个细节正常在没有代理的情况下客户端向服务器发送的请求行里只包含部分URI（实际上是没有方案，主机名及端口的）

如上图如果在没有代理的情况下，对www.baidu.com/index.html的请求的请求行实际上是GET /index.html HTTP/1.1 其实并不是我们常见的完整uri。因为在原始的HTTP设计中没有考虑中间服务器（即代理）的情况，客户端在发送报文前已经知道服务器的地址并与之建立了连接，没有必要再发送方案，主机名及端口。不过代理出现后这种做法就会有问题了，客户端连接了代理服务器，而代理服务器却没有办法连接正确的服务器。因此客户端发送给代理的请求其实稍有不同，客户端会在请求行里使用完整的uri，这样代理服务器才能解析真实的服务器的地址。

现在我们的请求实际上都是通过代理服务器（Fiddler 或 Charles）发送出去的，所以代理抓包软件不仅知道http请求及响应的所有报文，甚至还可以随时修改请求及响应。

部分应用不能抓包的原因

可以看到代理抓包的关键就是需要HTTP客户端按照要求去连接代理服务器，一般情况下我们已经在系统层面上设置了代理，通常http客户端都是按要求去实现的，在进行http请求前会先检查系统代理，如果有设置代理，客户端会直接使用完整uri去连接代理服务器。不同的平台通常会实现自己的的http客户端的，虽然他们都按照协议要求实现了代理功能，但是并不一定在默认情况下会直接使用系统代理。

在现实中这种况下这种情况还不少，笔者当前项目使用到的Flutter就是这种情况，默认Flutter不会主动使用系统代理，需要单独设置。（当然个人认为这种策略也是有理由，虽然给测试及调试带来了不便不过也在一程度上提高了些许数据安全）

正是因为HTTP客户端没有使用我们设置的系统代理，他们自然也不会连接Fiddler 或 Charles创建的代理服务器，最终导致我们无法获取任何请求。

解决方案

不过既然我们已经知道了Fiddler 和 Charles不能抓包的具体原因，前面也提到了代理抓包的原理，那我们就总有办法解决。

前面说到了我们APP使用的HTTP客户端没有连接到代理服务器，导致我们的代理抓包软件无法正常抓包，那我们只要想办法让客户端重新连接到代理服务器就好了（当然这一切都是以不修改客户端软件APP为前提的）

方法1：控制DNS解析，通过修改dns的方式让客户端以为我们的代理服务器就是目标服务器。

优势：操作方便，通过修改设备的hosts可以十分方便的首先

劣势：需要为每个需要操作的域名提前添加host

在手机等手持设备上难以修改hosts（即对移动APP这类应用很难实现）

方法2：在网络设备上直接做流量转发，将指定终端设备上发往80及443端口的数据直接转发到代理服务器的目标端口上

优势：可以针对连接到网络设备上的终端设备进行分别配置，而手机等终端设备不需要进行任何设备

劣势：需要单独的硬件设备

方法3：使用VPN将终端设备的流量转发到代理服务器

优势：使用VPN软件不用添加其他测试。

劣势：终端上的VPN默认会直接对所有流量进行转发，要进行合理的配置可能需要额外的学习成本

实际操作步骤

笔者这里直接使用上面提到第3种方法（方法1在对于手机APP很难操作，方法2可能需要其他设备所以这里不使用），因为我们的测试对象是手机移动APP，所以我们首先要在手机上安装一个VPN，这里使用一个十分方便的VPN软件drony （介绍在这里https://github.com/SuppSandroB/sandrop/wiki/Drony-FAQ），drony会在你的手机上创建一个VPN，将手机上的所有流量都重定向到drony自身（不是流向vpn服务器），这样drony就可以管理所有手机上的网络流量，甚至可以对手机上不同APP的流量进行单独配置。

1：安装drony （这里手机使用的Android设备）

您可以在网络上搜索drony选择自己想要的版本进行安装，或者在这里下载（https://files.cnblogs.com/files/lulianqi/Drony_102.apk），安装完成后打开软件如下图

2：开启代理抓包软件（这里代理抓包软件使用的是Fiddler）

Fiddler的使用这里不再介绍，需要打开远程代理，并在手机中安装Fiddler根证书

这里笔者开启的远程代理的地址是192.168.2.244:8888

关于证书安装有些细节，Fiddler默认的根证书是cer格式，部分手机可能只能识别pem格式证书

直接使用openssl 转一下就行了（openssl x509 -inform der -in FiddlerRoot.cer -out FiddlerRoot.pem）

openssl 在中 windows/mac 一般都安装有，命令直接使用就行了，使用生成的FiddlerRoot.pem安装到手机上就行了（Charles默认就是pem证书）

3：配置drony转发

打开Drony（处于OFF状态），滑动到SETING页，点击选择Networks Wi-Fi 进入配置

在网络列表中选择点击当前手机wifi连接的网络（需要确保该网络与Fiddler代理服务器网络是联通的）

配置要为当前网络使用的代理入口（这里直接填写fiddler代理地址就可以），选择代理模式为手动（Manual）

注意Proxy type代理方式要选择 Plain http proxy

Filter default value 选择 Direct all ，然后点击下面的Rule设置应用规则

默认您的规则里应该是空的，这里直接点击上面的加号添加一个规则（符合规则要求的才会被转发）

说明一下后面的操作会以咸鱼或支付宝做演示说明，不过笔者当前测试项目并不是咸鱼或支付宝，也不是其公司的员工，选择这2个APP做演示是因为这些APP比较常用，且无法抓包的原因与笔者当前项目APP是类似的。

在Network id处选择当前wifi的SSID

Action 选择 Local proxy chain

Application 选择需要强制代理的APP

Hostname 及 Port 不填表示所有的都会被强制代理，因为APP可能会使用其他的网络协议不一定都是http，可能不希望把所有流量都引流到http代理服务器，这个时候就会使用这个配置指定ip及端口才转发

完成后保存即可，然后返回到SETTING主页，滑动到LOG页，点击下面按钮，使其处于ON的状态（表示启用）

这个时候启动支付宝或咸鱼，我们就可以在Fiddler上看到正常的流量。不过如果你的运气与笔者一样可能只能看到这些Tunnel to （TLS管道建立），如果您使用的是Charles在列表里看到的可能是一个个红叉。

当然笔者Fiddler根证书是安装成功的，Fiddler配置也是正确的（手机上的Chrome https抓包都是正常的）

既然流量已经到Fiddler了，Drony的工作算是完美完成了，之所部分APP以不能解密https报文，还是我们自己证书的问题。首先先简单描述下证书校验的过程（如果不想看这些过程可以直接看后面操作步骤）

证书校验原理

无论Fiddler 或 Charles都使用中间人攻击的方式替换tls链路证书，解密报文然后再加密发送给真实服务器。

您可以参看 HTTPS中间人攻击实践（原理·实践）了解中间人攻击的细节

存在代理的情况下客户端首先连接的是代理服务器（即是图中的攻击者），实际client是直接与Proxy建立的TLS通道，所以代理当然TLS通道的传输密钥然后解密报文。

不过由于证书的存在，client会校验证书的合法性，然后决定是否连接服务器。我们使用Fiddler或Charles抓取https前在设备中安装根证书正是为了通过client的证书校验。

在浏览器中任意找一个https的网页，查看其证书信息。

从这里面我们能看到证书包含以下内容：

(1) Validity也即有效期，有效期包含生效时间和失效时间，是一个时间区间；

(2) 公钥信息Subject Public Key Info，包括公钥的加密算法和公钥内容；

(3) 指纹信息，指纹用于验证证书的完整性，也是证书校验的关键，他保证书没有被修改过。其原理就是在发布证书时，发布者根据指纹算法(此处证书使用了SHA-1和SHA-256算法有多个指纹是为了兼容老的客户端)计算整个证书的hash指纹【证书内容hash值使用CA私钥加密就是指纹】并和证书放在一起，client在打开证书时，自己也根据指纹算法计算一下证书的hash值，同时使用自己信任的根证书的公钥解密hash指纹计算出原始hash，如果hash值不一致，则表明证书内容被篡改过；

(4) 证书的签名Certificate Signature Value和Certificate Signature Algorithm，对证书签名所使用的Hash算法和Hash值；

(5) 签发该证书的CA机构Issuer；

(6) 该证书是签发给哪个组织/公司信息Subject；

(7) 证书版本Version、证书序列号Serial Number以及Extensions扩展信息等。

上图即是证书指纹校验的过程，可能看到Client校验证书的核心其实是CA公钥解密原始指纹，CA公钥从哪里来，为了确保安全设备系统会有一批自己信任的CA公钥列表（根证书）。这些CA公钥对应的一般是权威机构或组织，然后由这些权威机构颁发证书时会使用他们自己的私钥去签名（为证书生成指纹）。这样就确保了只有权威机构颁发给各个网站的证书才会被客户端校验通过。

Filddler没有这些证书里公钥对应的私钥（CA只会把为完整颁发的证书对应的私钥给网站的所有者），所以没有办法与客户端完成TLS握手。Filddler为了完成握手只能自己为不同的站点生成证书，

不过自己的生成的证书肯定是用自己的私钥签名的，客户端在自己信任的CA公钥列表找不到对应根证书，肯定是不能通过证书校验的。所以Filddler要求我们安装他的根证书到设备，这样自己签发的证书就可以通过证书校验，自己就能解密https报文了。

不能解密的原因

其实通过上面的描述也很明白了不能正常建立连接解密https报文的原因就是证书校验失败，我们的根证书安装不够完全。

从Android7.0以后，系统允许每个应用可以定义自己的可信CA集。有部分应用默认只会信任系统预装的CA证书，而不会信任用户安装的CA证书（或者说是应用使用的开发框架默认只信任系统证书，因为开发者通常不关心这些配置，也不会去更改他）。而在Android中用户安装的证书都是用户证书，所以无论是Filddler还是Charles我们都只是把他们的根证书安装到了用户证书，这些应用并不使用他们，所以我们的安装的证书是无效的。