HTTPS 的加密流程

HTTP【超文本传输协议】：HTTP 是一种能够获取如 HTML 这样的网络资源的 protocol(通讯协议)。它是在 Web 上进行数据交换的基础，是一种 client-server 协议，也就是说，请求通常是由像浏览器这样的接受方发起的。一个完整的 Web 文档通常是由不同的子文档拼接而成的，像是文本、布局描述、图片、视频、脚本等等。

然而，HTTP在web浏览器和网站服务器之间传递信息时，HTTP是以明文方式发送内容，这时如果黑客截取了浏览器和网站服务器之间的报文，就直接获取到了传输的信息，这是不安全的。
为了解决HTTP这一安全问题，诞生了在HTTP上+SSL协议：HTTPS协议—安全套接字层超文本传输协议。SSL通过证书来验证服务器的身份，对浏览器和服务器之间的通信进行加密。
HTTPS的主要作用有两种：

1. 建立一个安全的通信信道，保证数据传输的安全。
2. 确认网站的真实性。

关于HTTPS进行安全传输，最核心的就是如何进行加密？
加密分为两种：对称加密和非对称加密。

a（明文）+ key => b（密文） 加密的过程
b（密文）+ key => a（明文） 解密的过程
同一个密钥，既用来加密，又用来解密，就称为对称密钥。
而对称加密的安全性的前提是：密钥不被黑客所得知。

由于黑客并不知道密钥是啥，所以即使黑客截获的加密的数据，也并不能知道数据是什么意思。

由于一个服务器对应了多个客户端，每个客户端都要有不同的密钥。
如果客户端生成了一个密钥，客户端就需要把密钥告知给服务器，

然而，在客户端将生成的密钥发送给服务器的这一过程中，由于服务器并不知道密钥，因此必须明文传输，这时传输的明文密钥就很有可能被黑客截获。
如何解决这一问题，就需要想办法安全的把密钥传给服务器 - - - 加密传输给服务器 。

此处就用到了非对称加密：
非对称加密是生成了一对密钥：公钥和私钥；公钥是公开的，私钥是私藏的
明文 + 公钥 => 密文 ：使用公钥加密
密文 + 私钥 => 明文 ：使用私钥解密
（或者反过来）
服务器生成了一对公钥和私钥，客户端持有公钥，服务器持有私钥。
客户端的公钥是从服务器中获取的，黑客也可以知道公钥，但黑客不知道私钥，私钥是服务器自己所独有的，不会告诉别人。

客户端使用公钥，对对称密钥进行加密，传输给服务器，服务器用私钥解密，得到对称密钥后，客户端和服务器就可以使用对称密钥进行后续传输了。
【非对称加密只是用来传输对称密钥的，一旦对称密钥到达服务器后，后续的传输还继续使用对称加密】
为什么有了非对称加密，后续还要继续保留对称加密呢？
对称加密快
非对称加密慢
后续使用对称加密，可以尽可能提高整体的速度。

中间人攻击

解决中间人攻击的关键就是，让客户端能够辨别，当前这个给响应（公钥）是否是服务器真实的公钥。
引入一个证书（本质上是引入第三方的公证机构）

服务器（网站）在设立之初,就需要去专门的认证机构，申请证书(提供一些资质的)
审核通过,就会给你颁发证书.
服务器生成的公钥,也就包含在这个证书中了
客户端像服务器请求公钥的时候，此时就不是请求单单一个公钥, 而是把整个证书都请求过来

客户端拿到证书后，就可以对证书进行校验（验证证书是不是假的，是否被篡改）
如果发现证书是无效的，浏览器就会直接弹窗告警。

客户端如果对证书进行校验呢？
证书上有一个特定的字段：签名

证书
字段1：qqq
字段1：www
字段1：eee
公钥：0xqweasd
签名：xdtfcvghybkljhydfghu （被加密的字符串）

对于这里的签名，客户端可以使用认证机构提供的公钥对签名进行解密，解密后，得到的结果相当于是一个hash值。（根据证书中的其他字段，综合计算出的结果）

同理，客户端收到后，使用同样的hash算法，针对其他字段再次计算hash值，得到hash2，如果hash（签名中结出来的）和hash2（客户端自己算的）两个值相同，说明证书是有效的，没有被篡改的。

黑客能否篡改证书呢？
比如替换公钥：是不行的，一旦替换了公钥，客户端算的hash2和签名解密出的hash就对应不上了，就说明证书被篡改。
再者，黑客不知道认证机构的私钥，即使黑客自己算好的新的篡改之后的hash值，也无法加密生成签名。
（认证机构有一组公钥私钥，私钥用来加密hash值得到签名，公钥是客户端拥有的，使用公钥解密签名获取hash。）

参考文献：
https://developer.mozilla.org/zh-CN/docs/web/http/overview