HOW - Hybrid App 详解系列（四） - 具备真实证书的通用代理服务器

一、背景

1. whistle 手动配置不方便

在 HOW - Hybrid App 详解系列（二） - 开发调试 中我们发现使用 whistle 代理工具时，每台设备基本都需要重新安装证书和手动配置。

那有没有一种进阶方案，可以让我们省去每个开发每台设备都需要安装证书和手动配置？

2. 组织内通用的代理服务器

我们在 HOW - Hybrid App 详解系列（二） - 开发调试 中解释过：

当你在进行 HTTPS 通信时，通信的两端（客户端和服务器端）之间的数据是经过加密的，这种加密使得第三方无法轻易地窃听或篡改数据。当你使用类似 Whistle 这样的工具拦截 HTTPS 请求时，实际上你的浏览器会认为你正在与服务器进行通信，但实际上是与 Whistle 进行通信。为了使 Whistle 能够解密 HTTPS 请求和响应，它需要提供一个类似服务器的身份，并且需要一个证书。这个证书会被安装在你的系统中，作为一个“中间人”，用于在你和目标服务器之间进行通信的中转，同时解密和重新加密数据。这样 Whistle 就可以拦截并查看 HTTPS 请求和响应的内容了。

那我们是不是可以考虑自己搭建一个组织内通用的代理服务器来模拟 whistle 达到同样的拦截效果，并且可以寻求避免需要在每台设备上安装证书或手动配置代理的方案。

注意，这里说的是组织内，即前提是 内网环境。

因此在实际场景下，真机调试要求手机和电脑在同一局域网， 即内网WiFi或者外网+代理下。

但是另外在一些公司中，需要是测试机（IT 支持提前配置过的设备）才可以访问正常内网，对于这种限制，假如是多人一起开发，无法人均一台测试机的话，需要特殊的方式，后文会进行介绍，这里先简单说下步骤：

1. 内网手机开热点.
2. 自己手机连热点.
3. 自己手机设置代理.

二、具体实践

1. 思路和方案

1. 我们将搭建一个代理服务器，在服务器中我们会启动一个 whistle 服务。该代理服务器会提供一个“控制台界面”，会将服务器拦截的请求相关信息都展示出来。
2. 又因为目的是方便多人开发，该代理服务器还将提供一个“账号和环境配置页”，这样不同开发者可以根据需要选择不同项目不同环境的代理规则。参考 whistle，通过在 Rules 里管理环境，一条 rule 就是一个环境。具体操作会在下面介绍。
3. 接着，我们需要在计算机设备设置网络代理，将 http 和 https 请求都代理到这个代理服务器上。
4. 最后对于模拟器和手机，分别手动设置代理，将访问的目标 h5 页面的请求转发到计算机设备 ip 上，这样这些请求都会走第二步计算机配置的网络代理，从而在控制台进行展示。

为什么这样就不需要证书了？ 因为这个代理服务器根据不同项目，返回给浏览器的都是真实的证书，直接能解密。而 whistle 我们还记得吗，它是一个自签名证书。

因此，具体来说，我们的通用代理服务器应该具备如下特性：

1. 无感解密流量，不需要在设备手动安装证书。前提是需要在通用代理服务器上传对应请求域名真正的证书。
2. 多账号数据隔离，多人使用互相不影响。在之前 Whistle 或者 Charles 场景下，开发时需要每个人在自己电脑安装 Charles，然后在手机上安装对应的证书，当从另外的同事借了一台手机过来，此时想要实现抓包，需要重新安装自己电脑上 Charles 对应的证书到该手机上，过程繁琐。
3. 无视 SSL Pinning，就算客户端开了证书校验，也能抓包。
4. 抓包调试，历史记录，数据保存。

2. 使用步骤：模拟器版（推荐）

1. 安装模拟器

我们在 HOW - Hybrid App 详解系列（二） - 开发调试 中已经介绍过模拟器的安装和使用。

2. 设置计算机系统代理

假设我们的代理服务器 ip 地址和端口为：

ip: 10.123.101.111
port: 8080

以 Mac 为例，打开计算机系统“网页代理(HTTP)”和“安全网页代理(HTTPS)”，将这两个都设置为上述 ip 和端口。

然后假设我们的代理服务的控制台界面域名为：

proxy-console.companyinternal.com

需要同时将这个域名在“忽略这些主机与域的代理设置”中写入：

因为我们目标是把其他域名下的请求都代理到我们的代理服务器，其不包括我们代理服务的控制台界面。

3. 打开代理服务控制台界面并配置规则

访问 https://proxy-console.companyinternal.com/data.html，可以看到一个与 whistle 非常相似的界面。

进入 Rules，我们添加规则，假如我们希望在模拟器中 app 测试包里访问的 h5 能转发到本地启动的前端项目：

# 创建一个规则

# 转发 html 
# 将个人主页访问的路径转发到本地项目对应的路径
https://projectone-test.companyinternal.com/h5/homepage/page http://127.0.0.1:8081/h5/homepage/page

# 转发静态文件
# 将 dist 的访问的路径也转发到本地
https://projectone-test.companyinternal.com/h5/homepage/dist http://127.0.0.1:8081/h5/homepage/dist

配置好后：

4. 选择自己的账号和环境开始抓包

最后，在模拟器打开的 iOS 里，我们打开 Safari 浏览器，输入 http://10.123.101.111:8080，此时将打开账号和环境配置页，选择自己的账号以及刚刚创建的环境 rule，再打开 app 访问目标 h5 页面。

可以在控制台界面看到拦截的请求了。

3. 使用步骤：真机版

1. 准备工作

保证手机和计算机在一个局域网内。

2. clash 安装和转发

手机与模拟器不一样，模拟器载体就是计算机本身，因此设置系统代理即可。但手机需要另外通过一层转发才行。

1. 计算机安装和启动 clash
2. 手机 WiFi 设置里代理 ip 设置为计算机 ip，端口设置为 clash 启动的端口
3. 设置 clash 请求转发到通用的代理服务器

如此实现手机上访问目标 h5 的请求能被通用代理服务器拦截。

三、常见问题

1. 有的 APP 没法抓包：ssl pinning

因为他们 app 通过在代码中嵌入了证书或公钥，做了 ssl pinning。

SSL Pinning（也称为证书绑定或公钥绑定）是一种增强应用程序安全性的技术，它通过要求应用程序仅信任特定的 SSL/TLS 证书或公钥来防止中间人攻击。

简单来说，SSL Pinning 就是应用程序在与服务器建立安全连接时，会验证服务器返回的证书或公钥是否与预期的一致，而不是依赖操作系统或系统信任的证书列表。

当应用程序进行 SSL Pinning 时，它通常会将预期的证书或公钥直接嵌入到应用程序的代码中，或者将它们存储在应用程序的受保护存储区中，这样就不会依赖于设备上的证书存储或系统信任的证书列表。这样做可以防止恶意用户利用中间人攻击来窃取应用程序与服务器之间的敏感信息。

当应用程序使用 SSL Pinning 时，代理工具（如 mitmproxy）在尝试拦截与服务器之间的通信时，会遇到困难，因为即使它成功地将自己的证书插入到通信链路中，应用程序也会拒绝与它通信，除非它提供了应用程序预期的证书或公钥。

因此，即使您在设备上安装了代理服务器的证书，应用程序仍然无法被成功拦截。这就是为什么有些应用程序似乎“没法抓包”H5 网页请求的原因。这种情况下，您可能需要探索其他方法来分析应用程序的网络通信，或者尝试绕过 SSL Pinning 的技术，但请注意这样做可能会违反应用程序的使用条款或法律。