前面讲过，现在绝大部分通信都采用了HTTPS协议，使得在渗透过程中，会经常遇见https证书校验，从而导致不能抓取数据包。
几乎所有网络数据的抓包都是采用MITM的方式，包括常用的、等抓包工具。所以我们以抓包来描述中间人攻击。
现在的APP都是HTTPS服务提供商自己开发的，开发者可以先将自己服务器的证书打包内置到自己的APP中，或者将证书签名内置到APP中，当客户端在请求服务器建立连接期间收到服务器证书后，先使用内置的证书信息校验一下服务器证书是否合法，如果不合法，直接断开。
当APP是HTTPS时，单纯的使用无法抓取数据包，原因是APP启用了SSL (又称“SSL证书绑定”)。HTTPS建立有单向认证和双向认证两种情况，如下图所示：
单向认证的情况下，客户端只验证服务端是否合法，服务端对客户端不再进行验证。再看双向认证：
双向认证需要服务端支持，客户端必须内置一套公钥 + 私钥。在SSL/TLS握手过程中，服务端会向客户端请求证书，客户端必须将内置的公钥证书发给服务端，服务端验证公钥证书的真实性。双向认证内置的公钥+私钥是额外的一套，不同于证书固定内置的公钥证书。
双向认证时客户端也是有一个证书的，建立通信时不仅客户端要验证服务端的合法性，服务端还要验证客户端的合法性。这样APP抓包就有三种情况：
情况1，客户端不存在证书校验，服务器也不存在证书校验。
情况2，客户端存在校验服务端证书，服务器不存在证书校验，单项校验。
情况3，客户端存在证书校验，服务器也存在证书校验，双向校验。
情况1没有难度就不讨论了，在情况2的前提下，我们使用JD-GUI进行反编译，然后全局搜索： 或者 字符串，如下图：
这里可能会遇到SSL ，SSL 是一种防止中间人攻击的技术，主要机制是在客户端发起请求–>收到服务器发来的证书进行校验，如果收到的证书不被客户端信任，就直接断开连接不继续请求。可以发现中间人攻击的要点是伪造了一个假的服务端证书给了客户端，客户端误以为真。防御攻击思路就是，客户端也预置一份服务端的证书，比较一下就知道真假了。
SSL-有两种方式：
证书锁定（ ） 和公钥锁定（ Key ）。
证书锁定：
开发者在客户端代码内置仅接受指定域名的证书，而不接受操作系统或浏览器内置的CA根证书等任何证书，通过这种授权方式，保障了APP与服务端通信的唯一性和安全性，因此客户端与服务端之间的通信是可以保证绝对安全。但是CA签发证书都存在有效期问题，缺点是在证书续期后需要将证书重新内置到APP中。
公钥锁定：
提取证书中的公钥并内置到客户端中，通过与服务器对比公钥值来验证连接的正确性。制作证书密钥时，公钥在证书的续期前后都可以保持不变（即密钥对不变），所以可以避免证书有效期问题，一般推荐这种做法。
不过安全性高的都采用了证书锁定，比如微信在6.7.3版本以后就是采用证书锁定的方式，它不再信任系统内置的证书，而只信任自己的证书。而系统从7.0开始也不再信任用户CA证书，只信任系统内置的证书。
有两种绕过方式，方法一是在已经root的设备上安装CA证书，然后直接抓包即可，在本机无法取得root的情况下，通过模拟器也可抓到https数据包。方法二不需要root，而是通过反编译apk，找到校验证书方法，将校验部分删除，从而变成情况1，再编译apk，就可以抓取数据包。举个例子：利用.exe反编译apk文件，找到方法的smali代码，如图：
进行适当删改后：
反编译apk文件再查看其代码：
完成后，安装apk至设备，再次尝试抓包：
发现可以成功获取数据包。不过该方法有一个前提就是：客户端程序没有对自身完整性进行校验。否则是无法成功的。
前面我们提到有些APP不再信任用户安装的CA证书，也有一个绕过方法：在配置文件中修改g选项。
<manifest ... >
<application android:networkSecurityConfig="@xml/network_security_config">
......
application>
manifest>
然后在项目res目录下新增一个文件夹，命名为xml，然后在xml目录下新建一个fig.xml文件，命名跟上面匹配。
<network-security-config>
<base-config cleartextTrafficPermitted="true">
<trust-anchors>
<certificates src="system" />
<certificates src="user" />
trust-anchors>
base-config>
network-security-config>
这个配置即表示配置burpsuit谷歌浏览器证书及HSTS问题处理，APP信任用户CA证书，让系统对用户CA证书的校验给予通过。不过此方法往往只对少数apk管用，大部分APP都做了加固，很难通过该方法来绕过证书验证。
另外还可以调低 =26。2019年8月1日后必须>=28，国内应用市场也开始逐步响应这种限制。目前绝大多数APP的都大于24。所以这种方法基本行不通了，就算可以也不是长久之计。
还有一种方法就是可以使用平行空间或者来曲线救国。平行空间和这种多开应用可以作为宿主系统来运行其它应用，如果平行空间和的
最后一种方法是把CA证书安装到系统内置列表里，这种方法需要root。
然后来看实例，我先开一台虚拟机A伪造服务端，可以自签证书。用另一台电脑B正常上网（假装是受害者）。然后对B发起中间人攻击。
正常情况下，浏览器安全肯定不会这么脆弱，来看浏览器是如何借助HTTPS抵御中间人攻击的。用Edge浏览器访问。如图：
得利于TLS证书体系，虽然我们能发起中间人攻击，不过浏览器察觉到了证书的异常。因为浏览器一开始就知道自己需要连接的主机是，我们虽然通过网络劫持的方式让浏览器以为我们的服务器A就是，然而服务器A却没有的证书，使用的是自签的证书，前面也提到过浏览器会进行4步验证。最后发现我们证书签发的域名不是，自然就知道了当前网络的风险，然后阻止本次访问。
但是可以发现用户依然能选择"继续转到网页（不推荐）"。如果我们使用浏览器会是这样的：
明显对HSTS处理更为出色。因为对于已经开启严格安全传输HSTS的，浏览器发现证书错误后，的做法是强制禁止访问。 5、总结
上述中间人攻击实践中使用到了及仅是为了方便控制及调试中间人攻击的状态，实际操作中并不需要，也就是说你的手机不需要连接任何代理，因为往往流量的劫持发生在更隐蔽的网络节点中，如链路中的网络设备完全可以在无感的情况下将经过自己的流量转发到中间人服务器，或者这种劫持也可能由DNS解析引起。事实上ARP投毒，WPAD劫持，DNS欺骗，BGP路由劫持，都会为这种中间人攻击创造条件。
补充：我偶尔发现有的APP应用层使用的并非HTTP协议。比如微信和QQ，应用层使用的就不是HTTP协议，而是其私有的协议配置burpsuit谷歌浏览器证书及HSTS问题处理，这种情况需要使用其它的抓包工具从传输层分析，比如 这种直接解析TCP/UDP协议的，但是往往非HTTP协议的数据包即使抓到了也无法解析出来，因为大概率都是二进制而非文本格式的。比如QQ应用层是腾讯私有协议，传输层是TCP和UDP混用，而且做了加固防止反编译等等，安全性极高。
最后，针对HTTPS的中间人攻击，是建立在开发者没有正确的对证书进行校验的前提下。在这种证书校验不严格的前提下才能实施MITM攻击，如果证书校验严格的话，从理论上来讲是无法攻击的。网上那些教程，像利用或者进行中间人攻击，全部是针对HTTP协议的，但是他们普遍没有说明这一点。像这样的：
评论留言