国密TLS协议抓包实战：解决Android APP使用国密算法导致的BurpSuite抓包失败

在一次针对某银行安卓APP的安全测试中，设置代理并绕过常规抓包限制后，发现BurpSuite虽然能捕获到APP发出的关键业务请求，但服务端接收请求后并未返回正确的响应数据。具体表现为，BurpSuite的Response窗口一片空白，没有任何数据返回。

重放请求时提示：Received fatal alert: protocol version。

面对这种情况，发送请求后抓包工具收不到响应，在排除网络问题后，基本可以确定是服务器端做了某种校验。最常见的可能是HTTPS双向认证（mTLS），即服务端会校验客户端证书。因此，最初的排查方向便是检查是否存在客户端证书验证。

通过逆向分析，发现APP在发起请求时确实加载了客户端证书。于是尝试提取该证书及私钥，并将其导入到BurpSuite的客户端TLS证书配置中。

然而，导入证书后，请求依然失败，无法获取响应。但有趣的是，如果不通过代理进行中间人抓包，APP与服务器之间的网络通信是完全正常的。

我们需要理解代理抓取HTTPS流量的基本原理。在直连情况下，客户端与服务器进行一次完整的TLS握手和通信。而在代理抓包场景中，这段通信被分割为两段：第一段是客户端与中间人（代理）的通信，第二段是中间人（作为新的客户端）与服务器的通信。

所以，当前的情况是：客户端 — 服务器 通信正常，而 中间人（BurpSuite）— 服务器 通信异常（服务器不认可中间人发起的请求）。

那么，服务器为什么不认可呢？BurpSuite给出的错误信息过于笼统。于是尝试将请求的URL复制到浏览器中直接访问，此时访问客户端既不是APP，也不是BurpSuite，而是浏览器本身。

浏览器访问目标URL时明确提示：

1. 不支持的协议
2. 客户端和服务器不支持常用的 SSL 协议版本或密码套件

至此，线索指向了加密套件问题。服务器很可能使用了非标准的、浏览器默认不支持的密码套件。那么，这款Android APP究竟使用了什么密码套件呢？

接下来的分析表明，该APP使用了OkHttp3作为网络请求框架，而OkHttp3支持自定义TLS协议版本和加密套件。因此，编写了一段Frida Hook脚本，用于拦截并读取APP在初始化OkHttpClient时设置的连接规格（ConnectionSpec），从而获取其使用的具体协议和加密套件信息。

Java.perform(function() {
    try {
        var OkHttpClient = Java.use("okhttp3.OkHttpClient");
        var Builder = Java.use("okhttp3.OkHttpClient$Builder");
        console.log("[+] OkHttpClient loaded: " + !!OkHttpClient);
        console.log("[+] Builder loaded: " + !!Builder);
        Builder.build.implementation = function() {
            var client = this.build.call(this);
            // 获取和打印协议和加密套件信息
            var connectionSpecs = client.connectionSpecs();
            if (connectionSpecs) {
                for (var i = 0; i < connectionSpecs.size(); i++) {
                    var spec = connectionSpecs.get(i);
                    console.log("\n[+] ConnectionSpec<加密套件和协议版本信息>: \n" + spec);
                }
            }
            // 如果应用使用了客户端证书，你可以从这里获取它们
            var certificatePinner = client.certificatePinner();
            if (certificatePinner) {
                console.log("Certificate Pinner: " + certificatePinner);
            }
            return client;
        };
    } catch (e) {
        console.error("[-] Error: " + e.message);
    }
});

Hook输出清晰地显示，APP使用的加密套件是：[TLS_ECC_WITH_SM4_128_CBC_SM3]，TLS协议版本为TLS_1_1。

这正是国密SSL（SM2/SM3/SM4）算法套件。国密SSL协议正是以TLS 1.1标准为蓝本制定的。至此，问题根源水落石出：BurpSuite抓包失败，正是因为目标服务器使用了国密算法的TLS加密套件，而BurpSuite、浏览器等常见测试工具默认均不支持国密算法。

那么，如何进行抓包测试呢？目前发现有两款工具可以有效抓取国密TLS协议传输的HTTPS数据包：

1. GMProxy

   • 使用教程可参考其官网：https://www.gmproxy.cn/

2. Yakit

   • 官网地址：https://www.yaklang.io/
   • Yakit在MITM（中间人攻击）功能中提供了“国密支持”开关，开启后即可代理国密TLS流量。

使用支持国密的抓包工具（如Yakit）后，成功捕获到了APP与服务端之间的请求与响应数据。

后记

国密算法是国家密码局认定的国产商用密码算法。近年来，国家从战略层面大力推动国产密码算法在金融、电子政务等关键领域的应用，明确要求在这些领域全面推进自主可控密码技术。因此，越来越多的Web系统开始部署使用国密SSL证书和协议。可以预见，国产密码算法及相关产品将成为未来政务、企业网站的安全标配。

然而，目前主流的Web安全测试工具（如Burp Suite、SqlMap等）并不直接支持对国密SSL网站的安全检查，这给相关系统的安全评估带来了一定挑战。未来，在安全测试中可能会遇到越来越多使用国密TLS协议进行加密传输的应用。

所以，当大家在使用BurpSuite等传统工具遇到抓包失败，而客户端直接通信正常时，不妨多一个思路：检查一下目标是否使用了国密TLS协议。 希望这篇在云栈社区分享的实战经历，能为你解决类似问题提供一些参考。