从原理到实战，全面总结 Android HTTPS 抓包

你的支持对我意义重大！
🔥 Hi，我是小彭。本文已收录到 GitHub · Android-NoteBook 中。这里有 Android 进阶成长路线笔记 & 博客，有志同道合的朋友，欢迎跟着我一起成长。（联系方式 & 入群方式在 GitHub）

前言

网络请求抓包是研发过程中常见问题，无论是开发时的接口调试，还是测试时的数据检验，都有网络抓包的需求。随着 HTTPS 协议的推广以及手机系统安全性的升级，抓包的门槛可能会逐渐变高；
在这篇文章里，我将带你从原理到实战全面认识 HTTPS 抓包，既理解 HTTPS 抓包背后的实现原理，又掌握市面上已有的抓包方案。对于一些方案中存在的坑点我也一一列举并给出解决方法。如果能帮上忙，请务必点赞加关注，这真的对我非常重要。

1. HTTPS 工作原理

要说清楚 HTTPS 抓包的原理，首先需要先说清楚 HTTPS 实现数据安全传输的工作原理，主要分为三要素和三阶段。如果你对 HTTPS 安全传输的模型还比较模糊，记得先回顾下我们之前的讨论：加密、摘要、签名、证书，一次说明白!

三要素分别是：

加密： 通过对称加密算法实现
认证： 通过数字签名实现（因为私钥只有 “合法的发送方” 持有，其他人伪造的数字签名无法通过验证）
报文完整性： 通过数字签名实现（因为数字签名中使用了消息摘要，其他人篡改的消息无法通过验证）

三阶段分别是：

CA 证书校验： CA 证书校验发生在 TLS 的前两次握手，客户端和服务端通过 Client Hello、Server Hello 等报文获得服务端 CA 证书，客户端验证 CA 证书合法性，从而确认 CA 证书中的公钥合法性（大多数场景不会做双向认证，即服务端不会认证客户端合法性，这里先不考虑）；
密钥协商： 密钥协商发生在 TLS 的后两次握手，客户端和服务端分别基于公钥和私钥进行非对称加密通信，协商获得 Master Secret 对称加密私钥（不同算法的协商过程细节略有不同）；
数据传输： 数据传输发生在 TLS 握手之后，客户端和服务端基于协商的对称密钥进行对称加密通信。

—— 图片引用自 https 原理模板

2. HTTPS 抓包原理 - 中间人攻击

我们熟悉的 Fiddler、Charles 和 HttpCanary App 等抓包工具，其实都是采用了中间人攻击（Man-in-the-MiddleAttack，MITM）的方案： 将客户端的网络流量代理到 MITM 主机，再通过一系列的面板或工具将网络请求结构化地呈现出来。

如果拦截的是 HTTP 请求还好说，要是拦截的是 HTTPS 请求，首先就遇到第一个问题 —— 加密：

加密： 由于 HTTPS 通信中对称密钥 Master Secret 只有通信双方才持有，MITM 无法解密密文，导致在抓包工具上也只能看到一堆无意义的乱码。

要解决这个问题，只能想办法让 MITM 也获得这个对称密钥。此时，MITM 不仅要做流量拦截，还需要伪装成真实的客户端和服务端，与真实的通信双方分别建立独立的连接。我们来看下在中间人攻击下，HTTPS 的三阶段：

连接 1：客户端与中间人的 HTTPS 连接：

CA 证书校验： 客户端与 MITM 握手，MITM 返回一个 “调包” 的 CA 证书（为了让客户端验证 CA 证书通过，需要提前在系统上安装 MITM 的证书）；
密钥协商： 客户端和 MITM 基于 “调包” 的公钥和私钥进行非对称加密通信，协商获得对称密钥；
数据传输： 客户端和 MITM 基于协商的对称密钥进行对称加密通信，此时 MITM 就可以解密出明文。

连接 2：中间人与服务端的 HTTPS 连接：

CA 证书校验： MITM 与服务端握手，服务端返回 CA 证书，由于服务端证书本来就是合法的，因此 MITM 可以拿到服务端公钥；
密钥协商： MITM 和服务端分别基于公钥和私钥进行非对称加密通信，协商获得 Master Secret 对称加密私钥；
数据传输： MITM 和服务端基于协商的对称密钥进行对称加密通信。

到这里，MITM 就成功与真实的客户端和服务端建立了独立的连接，发送的密文在 MITM 上就可以成功解密出来了。

既然 HTTPS 可以被抓包，是否说明 HTTPS 不安全的？
这需要区分不同使用场景下安全的口径，在用户不知情的场景 HTTPS 完全可以保证数据安全传输，而对于用户主动授权的场景，用户需要为这个主动的行为承担相应的安全风险。

总结一下实现 HTTPS 抓包的基本步骤：

部署 MITM 代理服务器；
通过代理等方式将网络流量归集到 MITM 主机；
客户端信任 MITM CA 证书；
MITM 分别与客户端和服务端建立独立连接；
MITM 解密客户端和服务端的通信，并结构化地呈现出来。

3. 在 Android 上安装 CA 证书

在 Android 上安装 CA 证书，可以总结为三种，其中系统证书和用户证书都可以在系统设置中 信任的凭据 中查看：

系统证书： 系统 CA 证书安装在 /system/etc/security/cacerts/ 目录，只允许 Root 权限才能进行添加和删除。需要注意系统 CA 证书有特殊的命名格式：哈希值.0 ，转换方法可以参考：Android 内置证书文件。
用户证书： 用户 CA 证书安装在 /data/misc/user/0/cacerts-added/ 目录，由用户自行安装，可以在系统设置 安装证书 中进行安装。由于 Android 7.0 行为变更，对于 targetSdkVersion ≥ 24 的应用，系统不再默认信任用户证书，需要在配置中额外声明：

应用级 AndroidManifest.xml

<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
    <application android:networkSecurityConfig="@xml/network_security_config"
       ... >
        ...
    </application>
</manifest>

network_security_config.xml

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="true">
        <trust-anchors>
            <!-- Trust preinstalled CAs -->
            <certificates src="system" />
            <!-- HERE: Additionaly trus user added CAs -->
            <certificates src="user" />
        </trust-anchors>
    </base-config>
</network-security-config>

应用固定证书（Certificate Pinner）： 客户端可以直接内置信任的服务端证书来限制其接受的证书集，用自定义的 TrustManager 代替系统默认的 TrustManager。在 HTTPS 请求的证书校验阶段，只有其接受的证书集合可以校验通过，这也是规避中间人攻击的一种方案。例如：

protected static SSLSocketFactory getSSLSocketFactory(Context context, @ResId int[] certificates) {
    if (context == null) {
        throw new NullPointerException("context == null");
    }
    CertificateFactory certificateFactory;
    try {
        certificateFactory = CertificateFactory.getInstance("X.509");
        // Create a KeyStore containing our trusted CAs
        KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());
        keyStore.load(null, null);
        for (int i = 0; i < certificates.length; i++) {
            // 加载内置证书
            InputStream is = context.getResources().openRawResource(certificates[i]);
            keyStore.setCertificateEntry(String.valueOf(i), certificateFactory.generateCertificate(is));
            if (is != null) {
                is.close();
            }
        }
        // Create a TrustManager that trusts the CAs in our keyStore
        TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
        trustManagerFactory.init(keyStore);

        // Create an SSLContext that uses our TrustManager
        SSLContext sslContext = SSLContext.getInstance("TLS");
        sslContext.init(null, trustManagerFactory.getTrustManagers(), new SecureRandom());
        return sslContext.getSocketFactory();
    } catch (Exception e) {
        e.printStackTrace();
    }
    return null;
}

// 通过 OkHttp 的 API 设置证书
OkHttpClient.Builder builder = new OkHttpClient.Builder();

int[] certficates = new int[]{R.raw.media};
builder.socketFactory(getSSLSocketFactory(context, certficates));
...

突破 Android 7.0 用户 CA 证书限制
由于 Android 7.0 行为变更，对于 targetSdkVersion ≥ 24 的应用，系统不再默认信任用户证书，需要在应用的 AndroidManifest.xml 中增加 android:networkSecurityConfig 配置。如果你要抓包第三方应用，并且该应用没有配置，就需要采用一些手段来突破限制了：
方法 1 - 使用 Android 7.0 以下系统： 从源头抹平用户证书限制，这个最简单直接；
方法 2 - 使用平行空间等虚拟系统： 使用 HttpCanary 平行空间或 VMOS App 等虚拟系统，在手机上虚拟出 Android 7.0 以下系统环境；
方法 3 - 安装证书到系统证书目录： 需要 Root 权限，把 CA 证书直接安装到系统证书目录下。

4. Fiddler 使用技巧总结

Fiddler 目前主要是用在 Window 系统上的网络调试工具，最新版本的 Fiddler Everywhere 开始支持全平台了，但我体验下来觉得不少功能是缺失的，期待官方更新。下面的介绍是采用新版 Fiddler Everywhere，操作与旧版本上是类似的。

4.1 使用 Fiddler 进行 HTTPS 抓包

这里总结一下使用 Fiddler 进行抓包的主要步骤，其实就是按照 第 2 节 提到的 实现 HTTPS 抓包的基本步骤 的思路进行配置：

1、部署 MITM 代理服务器： 在电脑上启动 Fiddler，默认会在这台电脑的 8866 端口部署 Fiddler 的 Web 服务器，可以通过下图设置页面修改端口。因为我们是在手机上抓包，所以还必须勾选 Allow remote computers to connect ：

2、通过代理等方式将网络流量归集到 MITM 主机： 在电脑命令行执行 ipconfig 获得本地 IP 地址，然后将手机和电脑连接到同一个局域网下，再修改手机连接 Wifi 的高级设置，设置代理到电脑的 IP 地址和 8866 端口号。至此，你就可以在 Fiddler 上看到抓取的网络请求了，但还看不到 HTTPS 协议传输的数据，界面上会有一个 “加锁” 的图标提示：

3、客户端信任 MITM CA 证书： 首先需要在 Fiddler 上开启 Https 抓包功能，才能导出证书，在下图设置页面中，先点击 Trust root certificate，再勾选 Capture HTTPS traffic 选项。

然后，你需要把 CA 证书安装到手机上，有两种方式：先使用 Export root certificate 导出证书文件（默认导出到桌面），再自行将文件发送到手机上；也可以在手机浏览器上访问 ipv4.fiddler:8866/，点击 FiddlerRoot certificate 直接下载证书。

现在你已经成功把 CA 证书下载到手机上了，还需要手动安装证书。在系统设置中搜索 安装证书，找到刚才下载的 CA 证书并安装（不同手机系统界面不同）：

到这里，你已经顺利地在 Fiddler 上抓取到 HTTPS 请求了。最好在筛选栏上过滤干扰项，比如不重要的域名，CONNECT 握手验证请求：

过滤域名：contains juejin
过滤 Method：is not equals to CONNECT、HEAD
过滤 Content-Type：does not contains image/

提示： 事实上，Fiddler 能做的不止是 HTTP 抓包这么简单，它还支持非常多高级功能。如果你需要深入研究 Fiddler，建议你直接购买肖佳写的《HTTP抓包实战》，下面我总结一些我玩过的一些技巧。

4.2 Fiddler 报文重放测试

重放攻击（Replay Attacks）是指攻击者通过抓包的方式，得到一个客户端向服务端发送的真实请求报文，并重复发送给服务端的攻击行为。比如攻击者抓取到一个点赞、投票或领奖的请求报文，并重复发送给服务器。因为这个请求本身就是合法的，而且攻击者并未篡改请求内容，所以服务端会误以为是一个真实的有效请求。

在 Fiddler 上重放请求很简单，有两种方式：右键点击一个请求，选择 Replay→Reissue Requests 直接重放；或者选择 Edit in Composer 先编辑再重放。

我在项目中实际遇到过重放攻击，一个比较聪明的用户抓取到了 App 类似领金币的请求报文，然后用重放攻击薅了一波羊毛。防范重放方法是在请求中增加标识参数和数字签名（防篡改）：

时间戳： 服务端将当前请求的时间戳与服务器时间对比，如果超过了阈值（如 60s），则判定为过时请求。缺点是 60s 内的重放请求依然会被判定为有效；
流水号： 服务端将当前请求的流水号与服务端记录的流水号对比，如果收到一个非升序（相等或小于）则判定为过时请求。缺点是需要保证报文顺序。
一次性口令： 服务端用当前请求的一次性口令在服务端维护的口令表中查找，如果已经使用过该口令则判断为过时请求。缺点是需要维护口令表，实践中可以综合使用时间戳 + 一次性口令的方案，这样既避免了短时间内的重放攻击，服务端也只需要维护一小段时间窗口内的口令表。

4.3 Fiddler 弱网模拟

目前最新版本的 Fiddler Everywhere 还不支持弱网模拟，需要使用旧版本的 Fiddler Classic，配置路径为：Rules→Performances→Simulate Modem Speeds。

4.4 Fiddler 修改 HTTP 请求

Fiddler 本身是一个代理服务器，可以拦截 HTTP 请求 / 响应进行修改后再放行。在 Fiddler 上配置 Rule：

5. Charles 使用技巧总结

5.1 使用 Charles 进行 HTTPS 抓包

这里总结一下使用 Charles 进行抓包的主要步骤，其实就是按照 第 2 节 提到的 实现 HTTPS 抓包的基本步骤 的思路进行配置：

1、部署 MITM 代理服务器： 在电脑上启动 Charles，默认会在这台电脑的 8888 端口部署 Charles 的 Web 服务器，可以通过下图设置页面修改端口，这里最好不要使用默认端口号。

2、通过代理等方式将网络流量归集到 MITM 主机： 在电脑命令行执行 ipconfig 获得本地 IP 地址（也可以通过 Charles 的 Help→Local Ip Address 查看），然后将手机和电脑连接到同一个局域网下，再修改手机连接 Wifi 的高级设置，设置代理到电脑的 IP 地址和 8888 端口号。
3、客户端信任 MITM CA 证书： Charles 抓包也需要在手机上信任 Charles CA 证书。根据指引，会让你在手机浏览器访问 chls.pro/ssl 下载证书，安装证书的方法与 Fiddler 相同（踩坑记录：使用默认端口号 8888 时，访问 chls.pro/ssl 一直不会自动下载，修改端口号就可以了）。

到这里，你已经顺利地在 Charles 上抓取到 HTTPS 请求了。最好在筛选栏中过滤掉干扰项：

5.2 Charles 报文重放测试

在 Charles 上重放请求很简单，有两种方式：右键点击一个请求，选择 Repeat 或 Repeat Advanced 直接重放；或者选择 Compose 先编辑再重放。其中 Repeat Advanced 适合做压力测试。

5.3 Charles 弱网模拟

打开 Proxy→Throttle Settings 进入弱网配置页面，其中 Throttle preset 提供了多种预置的网络环境模拟配置，可以直接在此基础上修改。各个选项的含义如下：

Bandwidth 带宽： 单位时间内通过通信链路的数据量，即每秒传输的数据量；
Utilisation 利用率： 带宽利用率；
Round-trip latency 往返时延： 传输层概念，指报文在客户端和服务端之间一次往返通信的时延；
MTU 最大传输单元： 数据链路层概念，指数据帧可携带最大的有效载荷，在以太网中一般是 1500 字节。如果一个 IP 包大小超过了 MTU，则会进行 IP 分片；
Reliability 可靠性 / 丢包率： 指数据传输失败的概率；
Stability 稳定性 / 抖动率： 指网络环境的稳定性，如果网络不稳定，则数据传输的成功率也会不稳定。这个参数非常适合模拟移动网络；
Unstable quality range 不稳定质量范围： 指网路环境的不稳定范围。

5.4 Charles 修改 HTTP 请求

Charles 本身是一个代理服务器，可以拦截 HTTP 请求 / 响应进行修改后再放行。在 Charles 上配置 Rewrite：

6. 手机本地抓包方案

前面提到的 Fiddler、Charles 或者 Wireshark 等抓包方案的整个配置过程是比较繁琐的，比如需要配置手机代理、安装证书等。最大的缺点是都依赖于一台部署代理服务器的电脑，不能满足随时随地抓包的需求。实践中可以采用综合的抓包方案：在手机上使用本地抓包方案，无法满足需求时再使用 Fiddler 等方案补齐。

6.1 VPNService API

VPNService 是 Android 4.0 引入的 API，能够对系统流量进行截取且不需要 root 权限。我们熟悉的科学上网 Ap，其实就是运行了一个 VPNService 服务。在 VPN 运行时，通常在通知栏上会有相关的提示，比如 “已激活 VPN” 等。在系统设置中搜索 VPN，可以查看当前手机中提供 VPN 服务的应用，例如：

HttpCanary App

HttpCanary 是一款强大的针对安卓手机的网络分析工具，它的工作原理是基于 VPNService 部署了一个 MITM 代理服务器来抓取网络数据包。另外，HttpCanary 还支持破解双向认证抓包，具体操作参考：Android 平台 HTTPS 抓包全方案

不过，HttpCanary 在 Android 11 系统上抓取 HTTPS 请求会有问题，由于系统只允许从系统设置中手动选择安装证书，而目前 App 还没有适配这个问题，导致安装证书这一步就凉了。我提供两个解决方法：

1、使用低版本的手机（极其舒适）；
2、使用有 Root 权限的手机，手动把从 HttpCanary 内部存储空间中把证书捞出来，再转化为系统证书并安装。这个方案顺便还解决了第三方应用未配置 android:networkSecurityConfig 的问题。具体操作参考：安卓 11 httpcanary 小黄鸟系统证书的安装

有赞移动助手 App

有赞技术团队是我经常关注的团队之一，有赞移动助手 App 本地抓包方案是他们 19 年分享的一个手机本地抓包方案。有赞助手 App 的原理也是基于 Android VPNService 或 IOS NetworkExtension 搭建的代理服务器，由助手 App 与真实服务器完成 HTTP 请求，相当于是自实现的 HttpCanary。目前以小彭的积累还不能完全消化实现这个方案，就记录在这里提供个思路吧。

6.2 OkHttp 拦截器

对于基于 OkHttp 实现网络请求的应用，可以通过拦截器监控应用内的网络数据，再通过通知栏、桌面小部件等入口查看抓取的数据。目前业内已经有开源的实现可直接使用：

Chunk： 集成 Chunk 后，通知栏消息会显示监控到的网络请求，点击后可以进入分析页面。不过这个项目已经多年没有维护了，而且也不支持数据筛选，有些鸡肋。

滴滴 DoraemonKit

滴滴的哆啦A梦大家都比较熟悉了，是一款面向大前端产品的效率平台，目前已经发展成一个相对完整的生态，支持 Android 和 iOS 等多个平台。DoraemonKit 也提供了网络监听的能力，其原理同样是基于 OkHttp 拦截器。区别在于 DoraemonKit 是通过 AOP 注入的方式添加拦截器，所以初始化时不需要我们手动添加拦截器，这也很好地解决不同组件存在多个 OkHttpClient 的问题。相关源码：

HttpUrlConnectionProxyUtil

private static void addInterceptor(OkHttpClient.Builder builder) {
    // 判断当前是否已经添加了拦截器，如果已添加则返回
    for (Interceptor interceptor : builder.interceptors()) {
        if (interceptor instanceof DokitMockInterceptor) {
            return;
        }
    }

    builder
        //添加mock拦截器
        .addInterceptor(new DokitMockInterceptor())
        //添加大图检测拦截器
        .addInterceptor(new DokitLargePicInterceptor())
        //添加dokit拦截器
        .addInterceptor(new DokitCapInterceptor())
        //添加弱网 拦截器
        .addNetworkInterceptor(new DokitWeakNetworkInterceptor())
        // 添加扩展拦截器
        .addInterceptor(new DokitExtInterceptor());
}

优酷 Ribut

Ribut 是小彭交流群中的同学分享的，看了下目前这个项目还处于比较初期的阶段，期待后续的发展。它是阿里巴巴优酷技术团队研发的可视化调试架构，目标是通过工具化手段解决研发日常痛点问题，如网络抓包。其中网络抓包的大概思路分为两步：1、通过扫码建立与 PC 端连接；2、通过 OkHttp 拦截器抓取网络请求数据并转发到 PC 端。虽然严格来说还是依赖 PC 端，但是整体的体验是 OK 的。

7. 总结

说了这么多抓包的方案，让我们换个视角，App 反抓包有哪些方案，你知道吗？关注我，带你了解更多，我们下次见。

参考资料

《HTTP 抓包实战》—— 肖佳著
网络安全配置 —— Android 官方文档
Capturing and Inspecting Android Traffic —— Fiddler 官方文档
Install System CA Certificate on Android Emulator —— mitmproxy 文档
Android 平台 HTTPS 抓包全方案 —— MegatronKing 著
Https 在 Android 中的使用添加可信证书认证 —— JoeLitterStar 著
有赞移动助手 App 本地抓包方案 —— 杨彬（有赞）著

你的点赞对我意义重大！微信搜索公众号 [彭旭锐]，希望大家可以一起讨论技术，找到志同道合的朋友，我们下次见！