3
头图

你的支持对我意义重大!

🔥 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 上重放请求很简单,有两种方式:右键点击一个请求,选择 RepeatRepeat 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 反抓包有哪些方案,你知道吗?关注我,带你了解更多,我们下次见。

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

彭旭锐
20 声望6 粉丝