HTTPS 协议
哥几个来学 HTTPS 协议 啦 ~~
目录
一、HTTPS 是什么？
二、何为 “加密”
三、HTTPS 的工作过程
1. 引入对称加密
2. 引入非对称加密
3.引入证书
一、HTTPS 是什么？
HTTPS 也是一个应用层协议，是在 HTTP 协议上引入了一个加密层。
有关 HTTP 协议的大家可以去看我的往期文章：(4条消息) 网络通信 --- HTTP 协议初识_如画亦枫的博客-CSDN博客
https://blog.csdn.net/m0_64247824/article/details/130961460
为什么 要在 HTTP 协议上引入一个加密层呢？
原因就是 HTTP 协议内容都是按照文本的方式明文传输的，那么就会导致在传输过程中被一些不安好心的人给篡改。
大家回想一下当初自己还是一个电脑小萌新的时候，想要下载一个软件，但是下完之后发现怎么和我想要下载的不是同一个呀？？！！
比如我想下一个 视频快速播发器 ，结果那个下载链接变成了 QQ浏览器，这不是欺负老实人吗？
这种 内容被篡改的行为 就被称为 运营商劫持：
由于我们通过网络传输的任何数据包都会经过运营商 (电信、移动 等) 的网络设备 (路由器、交换机 等) ，那么运营商是需要在这些设备上悄咪咪地安装一个可以篡改信息的软件，那么就可以将你传输的数据内容进行解析，并篡改。
我们在点击 “下载按钮” 的时候，其实就是在给服务器发送了一个 HTTP 请求，获取到的 HTTP 响应就包含了该 APP 的下载链接。运营商劫持之后，就发现这个请求是要下载 视频快速播放器 的，那么就自动把交给用户的响应篡改成 QQ浏览器 的下载地址了~~
不止运营商可以劫持，其他的 黑客 也可以用类似的手段进行劫持，从而窃取用户隐私信息，或者篡改数据内容。因此，在互联网上，明文传输是十分危险的事情~~
而 HTTPS 就是在 HTTP 的基础上进行了加密，进一步保证了用户的信息安全。
二、何为 “加密”
加密就是把 明文(要传输的信息)进行一系列转换，变成 密文。
解密就是把 密文 再进行一系列转换，变成 明文。
在这个加密和解密的过程中，往往需要一个或多个中间数据来辅助这一过程，这样的数据称为 密钥。
例如，假设我想要向暗恋对象传递这样一条消息，“I LOVE YOU”，但是我们不想让其他人得知这个礼物的内容。在这种情况下，我们可以使用加密算法来将这句话转换成一个只有我和我的暗恋对象能够理解的密文。
在这个过程中，“I LOVE YOU”被称为明文，即可读的、未加密的信息；而密文则是这句话经过加密算法处理后的一段乱码，只有我和我的暗恋对象知道如何解密它。
为了加密这条消息并生成密文，我们需要使用一个密钥，该密钥是一个特殊的代码，可以将明文转换为密文。例如，我们可以通过将明文中的每个字母向左移动三个位置来生成密文“F ILSB VLR”。这里，“向左移动三个位置”就是我们使用的密钥。
在我将密文发送给我的暗恋对象之后，她需要使用同样的密钥才能解密我们的信息。只有使用正确的密钥，她才能将密文还原为明文，从而理解我们要传达的内容。
因此，这个例子中
- 明文是可读的消息：“I LOVE YOU”；
- 密文是使用特定密钥保护的加密消息：“F ILSB VLR”；
- 而密钥是一个特殊的代码，用于加密和解密数据：“向左移动三个位置”。
三、HTTPS 的工作过程
1. 引入对称加密
对称加密其实就是通过同一个 密钥 ，把 明文 加密成 密文 ，并且也能把 密文 解密成 明文 。
引入对称加密之后，即使数据被截获，由于黑客不知道 密钥 是什么，那么就无法进行 解密，自然就不知道请求的真实内容是什么了。
但是，真的有这么简单吗？
服务器所对应的客户端有很多很多个，那么给这些客户端提供的密钥是相同的还是不同的呢？
答案显然要是不同的。
如果所有客户端的密钥都是相同的，那么黑客也可以作为一个客户端来拿到这个密钥了呀~~
那么既然不同的客户端使用的是不同的密钥，那么这就要求客户端在连接服务器的时候自己先生成一个密钥，让每个客户端各自生成各自的，互不相关，那么就有不同的密钥了~~
但是，客户端生成的密钥也要通过网络传输传给服务器，如果黑客将这个密钥给劫持了，那么他就能拿着这个密钥来破解密文了呀：
那么就要对这个密钥进行再一次的加密~~ 但是难道要生成一个 密钥2，使用 密钥2 来对 密钥 进行加密？
那在传输 密钥2 的时候，这个 密钥2 也可能被黑客截取。
难道要在生成一个 密钥3 来对 密钥2 进行加密？
那在传输 密钥3 的时候，这个 密钥3 也可能被黑客截取 ......
而且，不同客户端使用不同密钥，服务器就需要维护每个客户端和每个密钥之间的关联关系，这也是个很麻烦的事情~~
看来此路不通，只能另谋出路了~~
2. 引入非对称加密
非对称加密要用到两个密钥，一个叫 公钥 ，一个叫 私钥 。
公钥 和 私钥 是相互配对的：
- 通过 公钥 对 明文 加密，变成 密文
- 通过 私钥 对 密文 解密，变成 明文
当然了，反过来使用也是可以滴：
- 通过 私钥 对 明文 加密，变成 密文
- 通过 公钥 对 密文 解密，变成 明文
使用 公钥 和 私钥 最大的缺点就是运算速度非常慢，比对称加密要慢很多。因此只是在开始阶段协商密钥的时候使用非对称加密，后续的传输仍然使用对称加密：
以下的流程会出现 3 种 密钥：
- ①非对称加密的 公钥pub
- ②非对称加密的 私钥pri
- ③对称加密的 密钥key
(公钥：顾名思义就是可以公开的；私钥：只有服务器才有的)
注意：客户端和服务器的业务数据传输，仍然是使用 对称加密 的方式（对称加密速度快，成本低）。为了保证对称 密钥key 能够安全到达服务器，引入了 非对称加密 来保护密钥。非对称密钥(公钥、私钥)使用完后，就可以不再使用了~~
但是但是，黑客一笑，生死难料：“你有张良计，我有过墙梯”。
接下来我们来看黑客是如何来骗、来偷袭服务器这个69岁老同志的：
黑客：如果我可以自己生成 一个 公钥pub2，和一个 私钥pri2，来骗取你的 密钥 key，那么阁下又该如何应对呢？
我们的应对之策就是引入 证书 ~~
3.引入证书
首先我们需要知道证书是什么：
这个证书可以理解成是一个结构化的字符串，里面包含了以下信息：
- 证书发布机构(这个证书的发布机构是非常权威的，世界上没几个)
- 证书有效期
- 公钥（这里的 公钥pub 和 服务器的 私钥pri 是一对，是由服务器提供给证书的）
- 证书所有者
- 加密后的签名(使用权威机构自己的 私钥pri2，而解密的 公钥pub2 在客户端的操作系统上)
- ......
我们着重来了解一下 签名 是什么：
针对一段数据(比如一个字符串)，也可以通过一些特定的算法，对这个字符串生成一个 “签名” 。并保证不同的数据，生成的 “签名” 差别很大。这样使用这样的签名就可以一定程度的区分不同的数据。
大家可以联想一下当你初高中想要请假的时候，想要出校门，那你就得给保安一张写有班主任签名的假条，保安见到这个 班主任签名，就认定这张假条不是伪造的，“见字如见人”。
常见的生成签名的算法有：MD5 和 SHA 系列
以 MD5 为例，我们不需要研究具体的计算 签名 的过程，只需要了解 MD5 的特点：
- 定长：无论多长的字符串，计算出来的 MD5 值都是固定长度 (16字节版本或者32字节版本)
- 分散：源字符串只要改变一点点，最终得到的 MD5 值都会差别很大。
- 不可逆：通过源字符串生成 MD5 很容易，但是通过 MD5 还原成原串理论上是不可能的。
正因为 MD5 有这样的特性，我们可以认为如果两个字符串的 MD5 值相同，则认为这两个字符串相同。
而 证书 里的 签名 是怎么来的？
证书里的 签名 是针对 证书 里的所有属性，通过 MD5 计算出来的。换而言之，如果 证书 里的属性有一点点被篡改了，那么这个 签名 都会有很大改变。
来看一下流程图：
为什么说在 第④步 的时候，黑客获取到这个证书不能篡改呢？
因为黑客要篡改需要：
1.把证书中的服务器的公钥pub替换成自己的公钥
2.黑客针对证书的各个属性重新计算签名
3.黑客把签名重新加密。如果想要加密，那么就务必知道权威机构的私钥pri2，否则客户端就无法使用存储在客户端的公钥pub2来解密。除非黑客能把这个权威机构给黑了，否则就无法对篡改后的证书进行加密，显然这件事是不可能的~~
而且在第⑤步客户端拿到证书之后，会对证书进行校验：
1.解密证书属性里的签名：客户端使用操作系统中内置的权威机构的公钥pub2，针对证书中使用 私钥pri2 加密的签名进行解密。得到了 初始签名（注意：这个初始签名是通过这个证书里属性中的 “加密后的签名” 解密的来的~~）。
2.通过证书里的所有属性计算签名：为了防止黑客对证书里的属性进行篡改，那么客户端就会使用同样的 MD5 算法，基于证书中的所有属性重新计算，得到现有的签名。
3.那么此时客户端就拥有了两个签名：①证书属性里的签名 ②通过发送过来的证书计算出来的签名。我们比较这两个签名是否相同，如果相同，说明证书中的数据都是未被篡改的原始数据。如果签名不同，说明证书被篡改过，此时客户端的浏览器弹框报错~~
这就是浏览器的受信任证书发布机构：
Chrome 浏览器，点击右上角的
选择 "设置"，搜索 "证书管理" ，即可看到以下界面~~
小总结：HTTPS 的工作过程是面试常考问题，大家主要要弄懂前两个流程，至于引入证书的那一部分大家了解即可~~
