…
<?xml version="1.0" encoding="utf-8"?>这样即表示，App信任用户CA证书，让系统对用户CA证书的校验给予通过。更多相关信息，详见
Network security configuration：
https://developer.android.com/training/articles/security-config
调低targetSdkVersion < 24
=====================================================================================
如果想抓一个App的包，可以找个历史版本，只需要其targetSdkVersion < 24即可。然而，随着GooglePlay开始限制targetSdkVersion，现在要求其必须>=26，2019年8月1日后必须>=28，国内应用市场也开始逐步响应这种限制。绝大多数App的targetSdkVersion都将大于24了，也就意味着抓HTTPS的包越来越难操作了。
平行空间抓包
====================================================================
如果我们希望抓targetSdkVersion >= 24的应用的包，那又该怎么办呢？我们可以使用平行空间或者VirtualApp来曲线救国。平行空间和VirtualApp这种多开应用可以作为宿主系统来运行其它应用，如果平行空间和VirtualApp的targetSdkVersion < 24，那么问题也就解决了。
在此，我推荐使用平行空间，相比部分开源的VirtualApp，平行空间运行得更加稳定。但必须注意平行空间的版本4.0.8625以下才是targetSdkVersion < 24，别安装错了。当然，HttpCanary的设置中是可以直接安装平行空间的。
安装到系统CA证书目录
=========================================================================
对于Root的机器，这是最完美最佳的解决方案。如果把CA证书安装到系统CA证书目录中，那这个假CA证书就是真正洗白了，不是真的也是真的了。由于系统CA证书格式都是特殊的.0格式，我们必须将抓包工具内置的CA证书以这种格式导出，HttpCanary直接提供了这种导出选项。
操作路径：设置 -> SSL证书设置 -> 导出HttpCanary根证书 -> System Trusted(.0)。
PS. 很不幸的HttpCanary v2.8.0前导出的证书名称可能不正确，建议升级到v2.8.0以上版本操作。
导出.0格式的证书后，可以使用MT管理器将.0文件复制到/etc/security/cacerts/目录下，或者通过adb remount然后push也可（这里稍微提一下，别在sdcard里找这个目录）。
Firefox证书安装
=========================================================================
火狐浏览器Firefox自行搞了一套CA证书管理，无论是系统CA证书还是用户CA证书，Firefox通通都不认可。这种情况，我们需要将CA证书通过特殊方式导入到Firefox中，否则Firefox浏览网页就无法工作了。
HttpCanary v2.8.0版本提供了Firefox证书导入选项。在设置 -> SSL证书设置 -> 添加HttpCanary根证书至Firefox 中：
点击右上角复制按钮将url复制到粘贴板，然后保持此页面不动，打开Firefox粘贴输入复制的url。
出现下载证书弹框后，一定要手动勾上：信任用来标志网站和信任用来标志电子邮件用户。然后确定即可。
公钥证书固定
====================================================================
证书固定（Certificate Pinning）是指Client端内置Server端真正的公钥证书。在HTTPS请求时，Server端发给客户端的公钥证书必须与Client端内置的公钥证书一致，请求才会成功。
在这种情况下，由于MITM Server创建的公钥证书和Client端内置的公钥证书不一致，MITM Server就无法伪装成真正的Server了。这时，抓包就表现为App网络错误。已知的知名应用，比如饿了么，就采用了证书固定。
另外，有些服务器采用的自签证书（证书不是由真正CA发行商签发的），这种情况App请求时必须使用证书固定。
证书固定的一般做法是，将公钥证书（.crt或者.cer等格式）内置到App中，然后创建TrustManager时将公钥证书加进去。很多应用还会将内置的公钥证书伪装起来或者加密，防止逆向提取，比如饿了么就伪装成了png，当然对公钥证书伪装或者加密没什么太大必要，纯粹自欺欺人罢了。
证书固定对抓包是个非常麻烦的阻碍，不过我们总是有办法绕过的，就是麻烦了点。
JustTrustMe破解证书固定
Xposed和Magisk都有相应的模块，用来破解证书固定，实现正常抓包。破解的原理大致是，Hook创建SSLContext等涉及TrustManager相关的方法，将固定的证书移除。
基于VirtualApp的Hook机制破解证书固定
Xposed和Magisk需要刷机等特殊处理，但是如果不想刷机折腾，我们还可以在VirtualApp中加入Hook代码，然后利用VirtualApp打开目标应用进行抓包。当然，有开发者已经实现了相关的功能。详见：
案例1：
https://github.com/PAGalaxyLab/VirtualHook
案例2：
https://github.com/rk700/CertUnpinning
不过，这里CertUnpinning插件的代码有点问题，要改改。
导入真正的公钥证书和私钥
如果Client固定了公钥证书，那么MITM Server必须持有真正的公钥证书和匹配的私钥。如果开发者具有真正服务端的公钥证书和私钥，（比如百度的公钥证书和私钥百度的后端开发肯定有），如果真有的话，可以将其导入HttpCanary中，也可以完成正常抓包。
在设置 -> SSL证书设置 -> 管理SSL导入证书 中，切换到服务端，然后导入公钥证书+私钥，支持.p12和.bks格式文件。
双向认证
==================================================================
SSL/TLS协议提供了双向认证的功能，即除了Client需要校验Server的真实性，Server也需要校验Client的真实性。这种情况，一般比较少，但是还是有部分应用是开启了双向认证的。比如匿名社交应用Soul部分接口就使用了双向认证。使用了双向认证的HTTPS请求，同样无法直接抓包。
关于双向认证的原理
首先，双向认证需要Server支持，Client必须内置一套公钥证书 + 私钥。在SSL/TLS握手过程中，Server端会向Client端请求证书，Client端必须将内置的公钥证书发给Server，Server验证公钥证书的真实性。
注意，这里的内置的公钥证书有区别于前面第5点的公钥证书固定，双向认证内置的公钥证书+私钥是额外的一套，不同于证书固定内置的公钥证书。
如果一个Client既使用证书固定，又使用双向认证，那么Client端应该内置一套公钥证书 + 一套公钥证书和私钥。第一套与Server端的公钥证书相同，用于Client端系统校验与Server发来的证书是否相同，即证书固定；第二套SSL/TLS握手时公钥证书发给Server端，Server端进行签名校验，即双向认证。
用于双向认证的公钥证书和私钥代表了Client端身份，所以其是隐秘的，一般都是用.p12或者.bks文件+密钥进行存放。由于是内置在Client中，存储的密钥一般也是写死在Client代码中，有些App为了防反编译会将密钥写到so库中，比如S匿名社交App，但是只要存在于Client端中都是有办法提取出来的。
双向认证抓包
这里以S匿名社交App为例，讲解下如何抓取使用了双向认证的App的HTTPS包。如果服务器使用了Nginx且开启了双向认证，抓包时会出现400 Bad Request的错误，如下：
有些服务器可能不会返回404，直接请求失败。接下来看，如何使用HttpCanary配置双向认证抓包。
首先，解压APK，提取出.p12或者.bks文件，二进制的文件一般存放都在raw或者assets目录。
将client.p12文件导入手机，然后在HttpCanary的设置 -> SSL证书设置 -> 管理SSL导入证书中，切换到客户端（因为需要配给MITM Client），然后导入.p12文件。
由于双向认证的公钥证书和私钥是受密钥保护的，所以需要输入密码：
一般通过逆向可以从APK中提取出密钥，具体操作这里略过。输入密钥后，需要输入映射域名，这里使用通配符*映射所有相关域名：
导入完成后如下：
可以点进证书详情查看细节，这个client.p12文件包含公钥证书和私钥，是用于双向认证的。
配置完成后，重新进行抓包，看看效果。
可以看到，之前400 Bad Request的两个要求双向认证的请求成功了！
SSL重协商
有些服务器可能会开启SSL重协商，即SSL/TLS握手成功后发送请求时服务器会要求重新握手。这种情况一般比较少，但是也不排除，已知的应用比如 10000社区 就使用了SSL重协商。
由于Android系统对SSL重协商是有限支持，所以部分系统版本抓包会失败，表现为网络异常。在Android 8.1以下，SslSocket是完全支持SSL重协商的，但是SSLEngine却是不支持SSL重协商的，而HttpCanary解析SSL/TLS使用的是SSLEngine。在Android 8.1及以上，SSLEngine和SslSocket统一了实现，故是支持SSL重协商的。
所以，如果确认服务器使用了SSL重协商，请使用8.1及以上版本系统进行抓包。
非Http协议抓包
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）文章来源：https://www.toymoban.com/news/detail-855783.html
总结
本文讲解了我对Android开发现状的一些看法，也许有些人会觉得我的观点不对，但我认为没有绝对的对与错，一切交给时间去证明吧！愿与各位坚守的同胞们互相学习，共同进步！文章来源地址https://www.toymoban.com/news/detail-855783.html
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！
来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！**
如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）
总结
本文讲解了我对Android开发现状的一些看法，也许有些人会觉得我的观点不对，但我认为没有绝对的对与错，一切交给时间去证明吧！愿与各位坚守的同胞们互相学习，共同进步！
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！
到了这里，关于Android高级架构师：Android平台HTTPS抓包解决方案及问题分析的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
