前言

由于之前的文章已经介绍过了HTTP , 这篇文章介绍 HTTPS 相对于 HTTP 做出的改进

开门见山:

HTTPS 是对 HTTP 的加强版

主要是对一些关键信息 进行了加密

一.两种加密方式

1.对称加密

公钥 + 明文 = 密文

密文 + 公钥 = 明文

2.非对称加密

举个例子就好比 小区邮箱

提供一把锁（公钥，是给邮递员的） ，和一把钥匙（私钥，自己吃有）

邮递员把你的信，通过这把锁，锁到你的信箱里（使用公钥加密）

然后你就可以拿着你的钥匙打开邮箱（使用私钥解密）

前提是 锁 和 钥匙 是配对的（也就是公钥和私钥是配对的）

二.HTTPS的工作过程

总的目标：针对HTTP 这里的 header 和 body 进行加密

1.对称加密

但是上图有个很明显的问题，客服务器如果给很多的客户端发对接，那么这些客户端拿的是同一个 密匙 吗？

很明显，必须要求这些客户端的密匙是不一样的，这样彼此才不知道对方的密匙是什么。

那么此时就要求每个客户端的密钥都不同，就需要每个客户端在和服务器进行连接的时候，把自己的密钥生成出来，客户端再通过网络发送给服务器

但是如果黑客把密钥进行了抓取，那么加密操作就形同虚设

那么如何进行解决呢，如果给密钥套上一层密钥可以吗？答案按是不行的，套多少次都会被截取。

2.非对称加密

跟前面说的一样 ， 使用公钥和私钥，也就是对称密钥！！

就是客户端和服务器都生成自己的公钥和私钥

1.客户端给服务器发送一条请求，专门要服务器的公钥

2.服务器把私钥藏好，把公钥给客户端（公钥可能被劫持）， 客户端使用公钥进行加密，再进行传输的时候，即使被黑客进行劫持，但是只有私钥才能解密，而私钥在服务器哪里！

3.服务器手里持有私钥，服务器可以对对称密钥进行解密，然后就可以得到了原始的对称密钥。

这里有个问题：既然已经引入了非对称加密，那么为什么还要引入对称加密呢？

 答案就是：效率。每个业务逻辑要求的是不一样的，引入非对称加密势必会影响到整体的性能，                         也就是在合适的场景下使用非对称加密。对称加密也有他自己的用武之地。

3.中间人问题

非对称加密其实还有一个比较隐蔽的问题，那就是中间人问题

总的来说就是

1. 黑客 把pub1 进行获取 ， 然后使用 自己的 pub 2 发给客户端，
2. 客户端信以为真，使用 pub2 进行加密转给了黑客，黑客使用 自己的 pri2 进行解密之后 ， 拿到了关键的对称密钥。
3. 还不算完，为了不让服务器发现，黑客还把这个对称密钥使用之前获取的 pub1 加密，发给了服务器。
4. 服务器以为是客户端发来的，那么就使用了pri 2 进行解密，得到了对称密钥。
5. 此时，三者都有了对称密钥，那么客户端和服务器之间的通信，就非常危险了!

🎈那么如何进行解决呢？

                                        ---------->答案就是引入公证机构

服务器再创建的时候，需要先向公证机构进行申请。公证机构根据服务器的一些属性颁发 证书，证书中包含 网站域名，服务器公钥，过期时间，数字签名（被加密后的校验和）等。服务器就会保存好这个证书。

数字签名就是公证机构针对证书中的各个属性，计算出一个校验和，然后使用自己的私钥进行加密。

公证机构会生成自己的公钥和密钥。公钥通过操作系统分发给各个服务器，私钥自己进行保存。

当两者再次进行通信的时候，客户端收到服务器的证书，然后使用内置的公钥进行解密出数字签名，如果发现一致，那么就意味着服务器的证书是公证机构颁发的，是可信的！ 因为服务器的数字签名是通过公证机构的对称密钥进行加密的。

---

总的来说：

https进行加密：

1. 对称加密，加密业务数据
2. 非对称加密，加密对称密钥
3. “中间人”攻击，发现问题！
4. 使用证书，校验服务器的公钥