http（S）系列之（三）：https单/双向认证区别

前言
没有梗了，挖槽，不是朕的风格，硬来一个：昨晚做梦妻妾成群，年收入超千万了，可惜被儿子一泡尿滋醒了

在这里插入图片描述

参考文献

扯一扯HTTPS单向认证、双向认证、抓包原理、反抓包策略
提醒：参考文献里面涉及到单向认证和双向认证的说明我个人感觉不是很严谨，因为这里的图解准确说应该是HTTPS单/双向认证SSL握手图解

正文

HTTPS中的S表示SSL或者TLS，就是在原HTTP的基础上加上一层用于数据加密、解密、身份认证的安全层，即

HTTP + 加密 + 认证 + 完整性保护 = HTTPS

HTTPS单向认证SSL握手

单向认证：客户端校验服务端证书即可
在这里插入图片描述

详细过程如下:

（1）客户端发起HTTPS请求，将SSL协议版本的信息发送给服务端，这里生成了一个客户端随机数，详细可查看上一篇SSL握手。

（2）服务端去CA机构申请来一份CA证书，在前面提过，证书里面有服务端公钥和签名。将CA证书发送给客户端

（3）客户端读取CA证书的明文信息，采用相同的hash散列函数计算得到信息摘要（hash目的：验证防止内容被修改），然后用操作系统带的CA的公钥去解密签名（因为签名是用CA的私钥加密的），对比证书中的信息摘要。如果一致，则证明证书是可信的，然后取出了服务端公钥

（4）客户端生成一个随机数（密钥F），用刚才等到的服务端B_公钥去加密这个随机数形成密文，发送给服务端。

（5）服务端用自己的B_私钥去解密这个密文，得到了密钥F

（6）服务端和客户端在后续通讯过程中就使用这个密钥F进行通信了。和之前的非对称加密不同，这里开始就是一种对称加密的方式

注：实际进行通信加密是采用对称加密，因为它的速率以及资源消耗远小于非对称加密。这里的SSL握手，只是采用非对称加密对对称密钥进行加解密，然后通过对称密钥对通信进行加密传输，解密应用。

HTTPS双向认证SSL握手

双向认证和单向认证原理基本差不多，单向认证客户端需要认证服务端，而在双向认证中增加了服务端对客户端的认证

在这里插入图片描述
双向认证详细过程如下：
（1）客户端发起请求，将SSL协议版本的信息发送给服务端，（这里生成了一个客户端随机数，详细可查看上一篇SSL握手）。
（2）服务端去CA机构申请来一份CA证书，在前面提过，证书里面有服务端公钥和签名。将CA证书发送给客户端
（3）客户端读取CA证书的明文信息，采用相同的hash散列函数计算得到信息摘要（hash目的：验证防止内容被修改），然后用操作系统带的CA的公钥去解密签名（因为签名是用CA的私钥加密的），对比证书中的信息摘要。如果一致，则证明证书是可信的，然后取出了服务端公钥
（4）在（3）中客户端校验服务端证书通过后，客户端发送自己的客户端证书给服务端，证书里面有客户端的公钥：C_公钥
（5）服务器对（4）中发送的客户端证书校验，然后获得客户端C_公钥
（6）客户端发送支持的对称加密方案给服务端，供其选择
（7）在（7）和（6）之间服务器端在客户端提供的加密方案中选择加密程度最高的加密方式；将加密方案通过使用之前获取到的公钥进行C_公钥加密，返回给客户端
（8）客户端用自己的C_私钥去解密选好的加密方案，客户端生成一个随机数（密钥F），用刚才等到的服务端B_公钥去加密这个随机数形成密文，发送给服务端。
（9）用服务端B_私钥去解密（加密算法是服务器在客户端提供的加密方案中选择的）得到密钥F
（10）双方用密钥F进行通信

总结单向认证和双向认证区别：

1.认证方向：单向认证是客户端验证服务器证书；双向认证不但客户端验证服务器证书，服务器也需要验证客户端证书；
2.认证过程：单向认证如通过浏览器访问某个网站，双向认证如使用U盾登入网上银行，需客户端和服务器相互认证。

没那么多多余的废话，以上自己总结，具体认证细节可以查看上一篇SSL/TLS握手

HTTPS基本思路总结

HTTPS在保证数据安全传输上使用对称加密和非对称加密相结合的方式来进行的，简单来说就是通过一次非对称加密算法进行了最终通信密钥的生成、确认和交换，然后在后续的通信过程中使用最终通信密钥进行对称加密通信。之所以不是全程非对称加密，是因为非对称加密的计算量大，影响通信效率。

抓包原理

HTTPS即使安全，也是能够被抓包的，常见的抓包工具有：Charles、fildder等。

常用的HTTPS抓包方式是作为中间人，对客户端伪装成服务端，对服务端伪装成客户端。简单来说：

截获客户端的HTTPS请求，伪装成中间人客户端去向服务端发送HTTPS请求
接受服务端返回，用自己的证书伪装成中间人服务端向客户端发送数据内容。

具体过程如下图所示：

在这里插入图片描述
注：（上图完全抄），图解步骤好生阅读，如果后面有后续这个理解很有帮助；如果没有，这个理解更重要~~~

反抓包策略

为了防止中间人攻击，可以使用SSL-Pinning的技术来反抓包。可以发现中间人攻击的要点的伪造了一个假的服务端证书给了客户端，客户端误以为真。解决思路就是，客户端也预置一份服务端的证书，比较一下就知道真假了。

SSL-pinning有两种方式：证书锁定（Certificate Pinning）和公钥锁定（ Public Key Pinning）。

证书锁定
需要在客户端代码内置仅接受指定域名的证书，而不接受操作系统或浏览器内置的CA根证书对应的任何证书，通过这种授权方式，保障了APP与服务端通信的唯一性和安全性，因此客户端与服务端（例如API网关）之间的通信是可以保证绝对安全。但是CA签发证书都存在有效期问题，缺点是在证书续期后需要将证书重新内置到APP中。

公钥锁定（推荐）
提取证书中的公钥并内置到客户端中，通过与服务器对比公钥值来验证连接的正确性。制作证书密钥时，公钥在证书的续期前后都可以保持不变（即密钥对不变），所以可以避免证书有效期问题，一般推荐这种做法。

突破SSL-Pinning抓包

在逆向界，一山更比一山高。
思路是这样的：内置证书或者公钥的时候，常常会有对比验证的函数，直接控制这个函数的返回结果让验证通过不就好了吗。
于是就有了一个突破SLL-Pinning的经典操作：采用Xposed+justTrustme模块。
这个方案使用的是JustTrustMe这个Xposed模块，它所做的事情就是将各种已知的的HTTP请求库中用于校验证书的API都进行Hook，使无论是否是可信证书的情况，校验结果返回都为正常状态，从而实现绕过证书检查的效果。
更多突破SSL-Pinning的方法请参考：当你写爬虫抓不到APP请求包的时候该怎么办？【中级篇】

未完待续

什么叫做犹豫未尽，这个就是了，这块只是个人很欠缺，所以后面还会有进一步的学习。http（s）安全后续：
1.http抓包和反抓包实践；
2.https抓包和反抓包实践：①fildder使用和反制；②SSL-Pinning抓包和反制；③未知