关于单向认证与双向认证

前言：我这里记录了关于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是否可靠（这个可能就是平常访问浏览器有红色的提示的原因）
* 返回的公钥是否能正确解开返回证书中的数字签名
* 服务器证书上的域名是否和服务器的实际域名相匹配
* 验证通过后，将继续进行通信，否则，终止通信

4、客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择。

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.crt 和 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证书，而且还需要绕过客户端的强校验

关于https跳过证书校验底层原理

参考文章：https://mojun.me/2019/11/26/https-tls/

这篇文章回答了在单向认证中为什么可以不走ssl验证而进行通信