关于单向认证与双向认证
前⾔：我这⾥记录了关于CA证书->https单向认证->抓包⼯具在https抓包原理->https双向认证->SSL pining原理和绕过以及⼀些细节的思考（不知道对或错）
CA证书
先来了解下关于CA证书
证书是⽤来证明公钥拥有者⾝份的凭证。
CA证书的由来
CA证书⼀般由证书认证机构（CA）签发，过程：
1、申请者⾃⼰通过⾮对称加密算法（RSA）⽣成对应的公钥和私钥，然后把需要的申请信息（国家，域名等）连同公钥（就是RSA⽣成的公钥）发送给证书认证机构（CA）
2、证书认证机构（CA）确认⽆误后通过消息摘要算法（MD5，SHA) 加密申请的CA证书中的信息，加密完的就叫信息摘要，然后把信息摘要⽤CA的私钥（申请的RSA私钥）进⾏加密，加密完的数据就是签名。
对于如上申请的证书中包含如下的内容：
1）RSA公钥
2）证书拥有者⾝份信息
3）数字证书认证机构（发⾏者）信息
4）发⾏者对这份⽂件的数字签名及使⽤的算法
5）证书的有效期
总结：CA证书包含以下信息：申请者公钥、信息摘要（申请者的组织信息和个⼈信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明⽂），同时包含⼀个签名sign（对信息摘要⽤RSA私钥加密的⼀段sign值）。
https单向认证
⽹上的⼀张图，我⾃⼰觉得好理解就拿过来放上去了
1、客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。
2、服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书（包含了公钥和数字签名）。
3、客户端使⽤服务端返回的信息验证服务器的合法性，包括：
* 证书是否过期（这个可能就是平常访问浏览器有红⾊的提⽰的原因）
* 发⾏服务器证书的CA是否可靠（这个可能就是平常访问浏览器有红⾊的提⽰的原因）
* 返回的公钥是否能正确解开返回证书中的数字签名
* 服务器证书上的域名是否和服务器的实际域名相匹配
* 验证通过后，将继续进⾏通信，否则，终⽌通信
xposed4、客户端向服务端发送⾃⼰所能⽀持的对称加密⽅案，供服务器端进⾏选择。
5、服务器端在客户端提供的加密⽅案中选择加密程度最⾼的加密⽅式。
6、服务器将选择好的加密⽅案通过明⽂⽅式返回给客户端。
7、客户端接收到服务端返回的加密⽅式后，使⽤该加密⽅式⽣成产⽣随机码，这个随机码则⽤作通信过程中对称加密的密钥，使⽤服务端返回的公钥进⾏加密，将加密后的随机码发送⾄服务端。
8、服务器收到客户端返回的加密信息后，使⽤CA的私钥进⾏解密，获取对称加密密钥。在接下来的会话中，服务器和客户端将会使⽤该对称加密密钥进⾏对称加密，保证通信过程中信息的安全。
个⼈理解：单向认证在认证⽅⾯，只有客户端对服务端的证书进⾏了验证，验证了这个SSL证书是否是可信的，⽽服务端并没有对客户端的相关信息进⾏验证，这就导致了下⾯抓包⼯具在https中进⾏抓包！
抓包⼯具在https抓包原理
1、客户端向服务器发起HTTPS请求。
2、Charles拦截客户端的请求，伪装成客户端向服务器进⾏请求。
3、服务器向“客户端”（实际上是Charles）返回服务器的CA证书。
4、Charles拦截服务器的响应，获取服务器证书公钥，然后⾃⼰制作⼀张证书，将服务器证书替换后发送给客户端。（这⼀步，Charles拿到了服务器证书的公钥）。
5、客户端接收到“服务器”（实际上是Charles）的证书后，⽣成⼀个对称密钥，⽤Charles的公钥加密，发送给“服务器”（Charles）。
6、Charles拦截客户端的响应，⽤⾃⼰Charles的私钥解密对称密钥，然后⽤服务器证书公钥加密，发送给服务器。（这⼀步，Charles拿到了对称密钥）。
7、服务器⽤⾃⼰的私钥解密对称密钥，向“客户端”（Charles）发送响应。
8、Charles拦截服务器的响应，替换成⾃⼰的证书后发送给客户端。
⾄此，连接建⽴，Charles拿到了服务器证书的公钥和客户端与服务器协商的对称密钥，之后就可以解密或者修改加密的报⽂了。
HTTPS抓包的原理还是挺简单的，简单来说，就是Charles作为"中间⼈代理"，拿到了服务器证书公钥和HTTPS连接的对称密钥，前提是客户端选择信任并安装Charles的CA证书，否则客户端就会"报警"并中⽌连接。这样看来，HTTPS还是很安全的。
这⾥就拿Charles如何实现https的抓包机制，重点在红⾊的标记字体中，红⾊的标记字体就体现在我们平常所讲的搭建抓包的时候需要在⼿机中导⼊抓包⼯具提供的CA证书，原因也就是这个！
可以看出这个流程，是符合https单向认证的流程验证，其实这个也就是https单向认证，唯⼀的不同就是多了⼀个中间⼈！
接下来我们继续来看下双向认证
https双向认证
1、客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。
2、服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书（包含了公钥和数字签名）
3、客户端使⽤服务端返回的信息验证服务器的合法性，验证通过后，将继续进⾏通信，否则，终⽌通信，其中包括：
* 证书是否过期
* 发⾏服务器证书的CA是否可靠
* 返回的公钥是否能正确解开返回证书中的数字签名
* 服务器证书上的域名是否和服务器的实际域名相匹配
4、服务端要求客户端发送客户端的证书（这个证书指的就是内置存储在当前APP中通信需要⽤的证书），客户端会将⾃⼰内置的证书发送⾄服务端（在APP中⼀般都是类似client.p12的⽂件等等的）
5、服务端验证客户端的证书，通过验证后，会获得客户端的公钥
6、客户端向服务端发送⾃⼰所能⽀持的对称加密⽅案，供服务器端进⾏选择
7、服务器端在客户端提供的加密⽅案中选择加密程度最⾼的加密⽅式
8、服务端将加密⽅案通过使⽤之前客户端提供给服务端的公钥进⾏加密，返回给客户端
9、客户端收到服务端返回的加密⽅案密⽂后，使⽤⾃⼰内置证书的私钥进⾏解密，获取具体加密⽅式，⽽后，产⽣该加密⽅式的随机码，⽤作加密过程中的密钥，使⽤之前从服务端证书中获取到的公钥进⾏加密后，发送给服务端
10、服务端收到客户端发送的消息后，使⽤⾃⼰的私钥进⾏解密，获取对称加密的密钥，在接下来的会话中，服务器和客户端将会使⽤该密码进⾏对称加密，保证通信过程中信息的安全。
ps：双向认证的客户端证书⼀般都可以是如openssl⽣成的⾃签名证书，包括 和 client.key，这两部分内容可以集成在 p12 证书中, p12 证书可以设置打开密码。
个⼈理解：
1、单向认证 SSL 协议不需要客户拥有CA证书。双向认证要求服务器和⽤户双⽅都有证书，客户端需要服务端证书的公钥，服务端需要客户端证书的公钥，双⽅拿到了之后会通过对通信的加密⽅式进⾏加密这种⽅法来进⾏互相认证，最后客户端再随机⽣成随机码进⾏对称加密的验证
问题：为什么通信的时候都是使⽤的对称加密？
答案：是因为⾮对称加密的计算量⼤，影响通信效率。
为什么之所以不是全程⾮对称加密，是因为⾮对称加密的计算量⼤，影响通信效率。
2、单向和双向认证在通信中都是基于对称加密来实现
关于SSL pining
虽然 HTTPS 采⽤了公钥和证书的加密和验证⽅式，但依然存在 MIM(中间⼈攻击)的可能性，因为证书
颁发机构可能被⿊客⼊侵，⽽ HTTPS 只验证了证书的合法性，并没有验证当前服务器是否是我们要访问的服务器。
SSL pining还是https单向认证的范畴之内，SSL pining唯⼀的作⽤就是为了解决被中间⼈攻击。
为了保证我们当前访问的服务器就是我们需要访问的服务器，需要通过 SSL Pinning 的⽅式来实现，其包括 Certificate Pinning 和 Public Key Pinning 两种。
证书锁定
证书锁定需要把服务器的证书提前下载并内置到客户端中，当请求发起时，通过⽐对证书内容来确定连接的合法性，但由于证书存在过期时间，因此当服务器端证书更换时，需同时更换客户端证书。
既然是要锁定证书，那么我们客户端上应该事先存在⼀个证书，我们才能锁定这个证书来验证我们真正的服务端，⽽不是代理⼯具伪造的服务端。
如果是锁定证书，那通常情况下会将证书放置在app/asset⽬录下。
具体操作：将APP代码内置仅接受指定域名的证书，⽽不接受操作系统或者浏览器内置的CA根证书对应的任何证书。
通过这种授权⽅式，保障了APP与服务端通信的唯⼀性和安全性，因此移动端APP与服务端（例如API⽹关）之间的通信可以保证绝对的安全。
公钥锁定
公钥锁定则需提取证书中的公钥内置到客户端中，通过⽐对公钥值来验证连接的合法性，由于证书更换依然可以保证公钥⼀致，所以公钥锁定不存在客户端频繁更换证书的问题。
绕过思路
SSL pining单向认证验证的是客户端这边，这样的话我们就可以进⾏控制
内置证书或者公钥的时候，常常会有对⽐验证的函数，它会如何验证？当我们抓包的时候，这⾥拿charles具体，charles作为中间⼈抓包，它返回给客户端的是它⾃⼰的证书，由于SSL pining，此时客户端会进⾏验证，发现你返回的证书和我代码中的验证流程不⼀样，那么就直接拒绝了，最后导致抓包失败！
那么该如何解决？
那么我们直接控制这个函数的返回结果让验证通过不就好了吗。
于是就有了⼀个突破SLL-Pinning的经典操作：采⽤Xposed+justTrustme模块。
这个⽅案使⽤的是JustTrustMe这个Xposed模块，它所做的事情就是将各种已知的的HTTP请求库中⽤于校验证书的API都进⾏Hook，使⽆论是否是可信证书的情况，校验结果返回都为正常状态，从⽽实现绕过证书检查的效果。
先来回顾下上⾯的双向验证⼀共有⼏步，⼀共有⼗步（⾃⼰可以去数下....）！
如果正常通过charles⼯具抓包的时候双向验证会如何处理？
在第三步就会被结束，原因就是返回给客户端的是charles的CA证书，不符合
然后再来讲下如果你把ssl pining绕过的技术使⽤在了双向验证的时候，会出现什么？
在第四步就会结束，虽然你绕过了客户端的验证，但是你逃不出服务端的验证，你返回给服务端的是charles的证书，不符合
如果是正常的双向验证的话，只需要导⼊存储在APP端的CA证书即可
但是基于ssl pinning的双向验证的话，需要导⼊存储在APP端的CA证书，⽽且还需要绕过客户端的强校验