HTTPS单向认证

HTTPS在单向认证传输的过程中会涉及到三个密钥：

服务端的公钥和私钥，用来进行非对称加密交换密钥

客户端生成的随机密钥，用来进行对称加密传输数据

认证过程

1.客户端向服务器发起HTTPS请求，连接到服务器的443端口

2.服务器将自己的CA证书发送给客户端，证书中包含如下信息：

公钥（密钥对中的公钥发送给客户端，而私钥只有服务端知道）

持有者信息

证书认证机构（CA）的信息

CA 对这份文件的数字签名及使用的算法

证书有效期

还有一些其他额外信息

3.客户端收到服务器端的CA证书之后，会对证书进行检查，验证其合法性（注①），如果证书合法，客户端随机产生一个密钥，然后用证书中的公钥加密这个随机密钥，发送给服务端（这里交换密钥的过程，是使用公私钥对进行非对称加密传输）

4.服务器接收到客户端发来的加密密钥后，用自己的私钥进行非对称解密获得客户端密钥，然后用客户端密钥对数据进行对称加密进行传输

5.客户端收到服务端发送来的加密数据，用客户端密钥对其进行对称解密，得到服务器发送的数据，整个HTTPS传输完成（交换密钥之后的传输过程为对称加密传输）

借网上的图：

HTTPS双向认证

HTTPS在单向认证传输的过程中会涉及到三个密钥：

服务端的公钥和私钥，用来进行非对称加密交换密钥

客户端的公钥和私钥，用来进行非对称加密协商加密方式

客户端生成的随机密钥，用来进行对称加密传输数据

认证过程

1.客户端向服务器发起HTTPS请求，连接到服务器的443端口

2.服务器将自己的CA证书发送给客户端，证书中包含信息与单项认证一致

3.客户端验证CA证书合法性，获得服务端公钥

4.客户端将自己的客户端证书发送给服务端，证书中包含客户端公钥

5.服务端接收到客户端证书，获得客户端公钥，

6.客户端发送自己支持的对称加密方案给服务端，让服务端从中选择

7.服务端选择一个加密方案后，将该加密方案使用客户端公钥加密后返回给客户端

8.客户端接收到加密后的加密方案后，使用客户端私钥解密，获得服务端选择的加密方案

9.客户端用服务端公钥加密客户端随机产生的一个密钥，发送给服务端

10.服务端接收后，使用服务端私钥解密加密后的密钥，协商交换完成

11.双方使用客户端产生的密钥进行数据加密传输（对称加密）

借网上的图：

双向认证和单项认证的区别

双向认证中的以下几步：

4.客户端将自己的客户端证书发送给服务端，证书中包含客户端公钥

5.服务端接收到客户端证书，获得客户端公钥，

6.客户端发送自己支持的对称加密方案给服务端，让服务端从中选择

7.服务端选择一个加密方案后，将该加密方案使用客户端公钥加密后返回给客户端

8.客户端接收到加密后的加密方案后，使用客户端私钥解密，获得服务端选择的加密方案

这一部分是服务端验证客户端证书，使用客户端公钥加密选择的加密方案发送给客户端，这一过程和单项认证的流程一样，保证了所选择的加密方案是只能被客户端解开的，这一过程是协商加密方案的过程，其他认证过程与单向认证一致。

关于客户端验证服务端CA证书合法性

CA 机构

为了让服务端的公钥被大家信任，就产生了这样一种机构，Certificate Authority——证书认证机构，CA机构必须是具有极高可信度的，以保证签发的证书也是可信的

客户端验证CA证书合法性

客户端的证书管理目录中，会存在一些操作系统默认的受信任的根证书颁发机构，例如下图中这些：

客户端也可以自己添加一些机构进去，（例如使用BurpSuite进行抓包，就需要自己添加PortSwigger CA为受信任的跟证书颁发机构）

这样在服务端向客户端返回证书之后，客户端可以根据服务端证书是否由受信任的根证书颁发机构颁发的证书来验证CA证书是否合法。

但并不是所有的证书都是由根证书颁发机构来颁发的，相反大多数证书是层级颁发的，其中验证流程是层级验证是否可信，以我个人博客的证书来举例：

证书颁发者是R3，但是我的证书管理目录中并没有这个机构，那么客户端会向上一层验证R3这个中间证书的颁发机构是否可信。

R3的颁发机构为ISRG Root X1，此时客户端在受信任的根证书颁发机构中可以找到这个机构，那么就可以认证此证书为可信证书。

以上就是客户端验证服务端CA证书是否可信的大致流程，相应的，当我设置浏览器上级代理为BurpSuite时，那么客户端（浏览器）认为BurpSuite就是服务端，认证的证书就会变成。

而我已经将PortSwigger CA添加至我的受信任的根证书颁发机构目录中，所以浏览器也会认为证书是可信的，这也是为什么使用Burp抓包前需要先配置添加证书，然后BurpSuite再伪装成客户端与真正的服务端进行通讯，再将接收到的数据返回给真正的客户端，从而起到了代理的作用。

APP的HTTPS双向认证防止抓包

在app抓包中，使用了https双向认证的app，在验证服务端时，Burp可以伪造成服务端与app进行通讯，但是在Burp伪造成客户端时，服务端要求客户端提供客户端自己的CA证书，但是此时BurpSuite伪造的客户端CA证书服务端是不认的，因为app将证书内置在了app内部作为客户端证书，所以可以通过逆向app程序获得CA证书，再将app中的CA证书导入到Burp中即可来突破https双向认证防止抓包的限制

一个踩坑app双向认证的文章：https://www.cnblogs.com/pt007/p/11883924.html

总结

理解HTTPS协议的认证流程，可以增加对安全的理解，HTTPS认证的过程，核心思想与Kerberos协议的认证也是互通的，是具有相似性的。