今天我们要聊一聊网络方面的内容，这里主要结合以下问题对HTTPS做下简短总结：
- HTTPS为什么比HTTP安全？
- HTTPS的底层原理如何实现？
- HTTPS网站抓包为什么要信任证书?
- 客户端是如何校验证书合法性的?
- Https如何防止中间人攻击？`
HTTP与HTTPS协议
什么是HTTP？
HTTP(HyperText Transfer Protocol) 超⽂本传输协议。
是一个基于请求与响应，无状态的，应用层的协议, 在计算机世界里传输⽂字、图⽚、⾳频、视频等超文本数据的约定和规范，通常运行在TCP协议之上。它是一个明文协议，客户端发起请求，服务端给出响应的响应，存在信息窃听、信息篡改和信息劫持的风险。
什么是HTTPS？
HTTPS(Secure Hypertext Transfer Protocol)安全超文本传输协议。
HTTPS = HTTP + SSL/TLS，是HTTP协议的安全版，用于在客户计算机和服务器之间交换信息。
什么是SSL/TLS？
SSL/TLS 是介于 TCP 和 HTTP 之间的一层安全协议，具有身份验证、信息加密和完整性校验的功能。
SSL/TLS = 非对称加密（如RSA） + 对称加密（如AES、DES） + 散列算法（如MD5）
SSL的全称是Secure Sockets Layer，即安全套接层协议，是为网络通信提供安全及数据完整性的一种安全协议。
TLS的全称是Transport Layer Security，即安全传输层协议，是建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本。
HTTPS的实现原理
[图片上传失败...(image-490fc9-1646320977316)]
HTTPS 协议之所以是安全的是因为 HTTPS 协议采用混合加密机制，会对传输的数据进行加密，而加密过程是使用了非对称加密实现。但其实，HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段。
HTTPS协议引入了CA和数字证书的概念。
CA
数字证书签发机构，权威CA是受操作系统信任的，证书机构的CA证书内置在浏览器或操作系统中，也就是客户端本地，称之为CA根证书。
数字证书（Certificate）
数字证书的作用：
确保数据接收者的公钥是没有被篡改过的。
数字证书通常包含以下信息：
(1) 证书申请者的公钥;
(2) 证书发行者对证书的数字签名；
(3) 证书所用的签名算法；
(4) 证书颁发机构、申请者信息、有效期等其他信息明文。
数字证书的验证过程需要用到 CA根证书 和 服务端相关证书，CA根证书 是内置在浏览器或操作系统的。
数字签名
公钥和私钥是一一对应关系。
如果用「公钥」对数据加密，用「私钥」去解密，这是加密；
反之用「私钥」对数据加密，用「公钥」去解密，这是签名。
用Hash算法对数据进行计算得到Hash值，利用私钥对该Hash加密得到签名。
只有匹配的公钥才能解密出签名，来保证签名是本人私钥签发的。因为公钥和私钥是一一对应的，所以当一个公钥能解密某个密文时，说明这个密文一定来自于私钥持有者。
数字证书签发过程
- 网站生成密钥对，将私钥自己保存，公钥和网站域名等信息提交给CA
- CA把证书签发机构(自己)、证书有效期、网站的公钥、网站域名等信息以明文形式写入到一个文本文件
- CA选择一个指纹算法(一般为hash算法)计算文本文件的内容得到指纹(也可理解成证书编号)，用CA的私钥对指纹和指纹算法(生成指纹或者证书编号的方法)进行加密得到数字签名，签名算法包含在证书的明文部分
- CA把明文证书、指纹、指纹算法、数字签名等信息打包在一起得到证书下发给服务器
- 此时服务器拥有了权威CA颁发的数字证书以及自己的私钥
证书验证过程
- 浏览器以HTTPS协议请求服务器的443端口
- 服务器下发自己的数字证书给浏览器
- 浏览器先校验CA、有效期、域名是否有效，如果无效，则终止连接(服务器此时不可信任)
- 如果有效，则从操作系统取出证书颁发机构的公钥，根据签名算法对数字签名解密得到证书指纹和指纹算法
- 浏览器用解密得到的指纹算法计算证书的指纹(用指纹算法重新进行计算得到一份证书指纹)，与解密得到的证书指纹进行比对，如果一致，证书有效，公钥也安全拿到了
- 浏览器此时已经和真实的服务器进行通信了，中间人无法得知通信内容，因为中间人没有网站私钥
数据传输过程
- 当证书验证合法后，在本地生成随机数(也就是后面通信过程中对称加密的密钥)
- 通过公钥加密随机数，并把加密后的随机数传输到服务端
- 服务端通过私钥对随机数进行解密
- 服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输，此时两者基于此密钥可进行数据传输
HTTPS中间人攻击
中间人尝试第一波攻击
- 客户端向服务端发送消息say hello，被代理服务器拦截，然后代理服务器向真正的服务器发相同的say hello
- 此时服务器以为对方是客户端(不知道具体是谁，只知道是请求者)，下发自己的数字证书给到对方（此时对方是代理服务器）
代理服务器拿到证书再转发给客户端- 客户端获取到证书后进行校验，发现没问题，随后用服务端公钥将对称密钥加密发送给代理服务器
- 代理服务器接收到客户端消息后，完全懵了，因为没有真正服务端的私钥，无法解密查看这个对称密钥，既然看不懂，还把
消息原封不动的给了服务端 - 服务端接收到消息，查看没毛病，使用私钥解密对称密钥，对消息进行加密，把加密消息发给代理服务器
- 代理服务器因为刚刚不知道那个对称密钥是什么，自然看不懂传递的消息，纯粹是个中转消息的工具人，
这也就是使用了HTTPS之后，抓包截取到的数据都是乱码的原因。
中间人尝试第二波攻击
由于第一波的攻击发现自己白忙活了一场，纯粹是个工具人，什么便宜也没捞到，所以准备自己伪造个假的证书，看看能不能有点收获，流程如下：
- 客户端向服务端发送消息say hello，被代理服务器拦截，然后代理服务器向真正的服务器发相同的say hello
- 此时服务器以为对方是客户端(不知道具体是谁，只知道是请求者)，下发自己的数字证书给到对方（此时对方是代理服务器）
代理服务器拿到证书后，自己伪造一个假的证书发送给客户端- 客户端获取到证书后进行校验，发现证书有问题，但是
客户端选择了信任(此处先信任) - 客户端随后用伪造证书中的假公钥将对称密钥加密发送给代理服务器
- 代理服务器接劫持了客户端消息后，用自己的私钥解密得到了对称密钥，从而能够窃听或者篡改通信数据
- 代理服务器利用服务器的真实公钥将客户端的对称密钥加密发往服务器
- 服务器利用私钥解密这个对称密钥之后与代理服务器通信
- 代理服务器利用对称密钥解密服务器的数据，篡改之后利用对称密钥加密再发给客户端
- 此时客户端收到的数据已经是不安全的了
此时代理服务器得意洋洋的认为总算有点收获了，但这个流程有个问题，因为伪造的证书客户端是能校验出来的，上面客户端需要选择信任该证书，代理服务器才能有所收获，这也就是HTTPS抓包为什么要信任证书的原因。如果客户端选择了不信任，那代理服务器也不会有收获。
中间人尝试第三波攻击
第二波攻击还是有很大缺陷，这个伪造的证书已经被人发现了，如果不信任的话又徒劳无功。那我准备个让你查不出来毛病的证书试试，开始准备第三波攻击，步骤如下：
- 客户端向服务端发送消息say hello，被代理服务器拦截，代理服务器自己也准备了一个CA颁发的证书，把自己的合法证书发送给客户端，客户端进行校验没问题，信任
- 代理服务器向真正的服务器发相同的say hello，此时服务器以为对方是客户端(不知道具体是谁，只知道是请求者)，下发自己的数字证书给到对方（此时对方是代理服务器），代理服务器假装自己是客户端，信任了证书，校验通过
- 目前代理服务器作为客户端和真正的服务器建立了合法的通信，客户端在校验了代理服务器自己的证书后也建立了合法的通信
- 此时代理服务器作为中间人，因为他有自己的私钥和真正的公钥，可以欺上瞒下，两边的信息都从它这里中转，信息被他偷窥到。攻击成功。
从此代理服务器可以翘着二郎腿好好欣赏自己的成果了。
如何防御中间人攻击？
客户端内置真正的公钥，当代理服务器把它自己的证书传过来的时候，客户端用内置的公钥去解密证书中的签名，因为不是真正的私钥(不是真正服务器给的私钥)加密的所以解密失败，校验也就失败，连接中断。这也就是客户端信任所有的证书的风险，容易被中间人攻击。
总结
- 操作系统内置权威CA公钥来保证数字签名以及数字证书的安全性
- HTTPS网站抓包类似中间人攻击需要手动信任攻击者的假证书
