HTTPS

HTTPS是要比HTTP更安全

HTTP是一个明文传输的协议，本来传的试是啥，实际传的就是啥。

一旦传输过程中，数据被第三方获取到了，可能就会造成一些重要信息的泄露

HTTPS就是在HTTP的基础之上，引入了一个加密层(SSL/TLS),简单来说HTTPS就是由HTTP和SSL组成的

明文：真正要传输的消息

密文：指的就是加密之后的消息
明文 => 密文称为 "加密"

密文 => 明文称为 "解密"

密钥就是解密用的

加密

加密的过程中，又分成两种加密方式

对称加密

加密：明文 => 密文使用一个密钥

解密：密文 => 明文使用同一个密钥

非对称加密

加密：明文 => 密文使用密钥1

解密：密文 => 明文使用密钥2

密钥1和秘钥2是不同的秘钥(虽然这俩秘钥不同，但是存在关联关系的，这两个秘钥是成对出现的)

可以使用密钥1加密，使用密钥2解密；也可以使用密钥2加密，使用密钥1解密

通常会把其中一个密钥给公开出去，别人就可以使用这个密钥来加密了。自己留下另外一个密钥，用来解密。

把公开出去的秘钥称为"公钥"，把自己保留的秘钥称为"私钥"。

这里的公钥和私钥，就可以想象成现实生活中的信箱

公钥就像信箱上的锁，私钥就像这把锁的钥匙。

对称加密

先使用对称加密的方式，针对HTTP中传输的数据加密

对称加密里最关键的就是这个密钥，客户端和服务器需要约定好密钥是啥

如果是客户端生成了密钥，就需要通过网络告知服务器，密钥是啥

密钥本身也在网络上文明传输，也容易被黑客获取，一旦被黑客获取到了了，后续的加密就失去了意义。

正确的手段，是针对这个对称密钥，进行加密

非对称加密

引入非对称加密，使用非对称加密来对对称密钥进行加密

一个网站，生成一对公钥和私钥，把公钥公开出去，自己保留私钥

客户端就先拿这个网站的公钥来对自己的对称密钥进行加密，然后传输密文给服务器，服务器拿私钥解密，也就得到了密钥的明文。

只要有了个密钥，后续就可以直击使用对称加密来进行传输

既然都有非对称加密了，为啥还非得用对称加密呢？

对称加密，成本是比较低(机器资源消耗少)，速度也是很快的

非对称加密，成本比对称加密高很多(机器资源消耗的多)，速度也慢

中间人攻击

通过非对称加密的手段，确实是可以更安全的进行数据传输，但是还有点问题，就是客户端是如何获取到公钥的？

如何保证客户端获取到的公钥是真实可靠的，而不是黑客伪造的？

任何人都可以生成一对公钥和私钥，网站服务器能生成，黑客也一样能生成。

黑客就想到一招，狸猫换太子

如果黑客入侵了网路设备，在客户端向服务器获取公钥的时候，把自己生成的公钥和私钥进行了替换，那么此时客户端拿到的公钥就会是黑客伪造的公钥。

引入证书

为了解决中间人攻击的问题，就可以引入证书来反制黑客伪造公钥这个问题

客户端和服务器连接的时候，客户端不是简单的索要公钥了，而是直接索要一个"证书"，公钥就包含在这个证书里面

然后这个证书不是服务自己生成的，而是第三方机构颁发的

然后客户端拿到证书之后，就可以根据证书中提供的信息，去第三方机构进行认证，来校验证书是否合法。

证书如果合法，那么就可以信任其中的公钥。

服务器开发中在搭建服务器的时候要去第三方机构来进行认证，申请证书

证书也是可以伪造的，浏览器会对拿到的证书进行校验，如果校验不通过浏览器就会有错误提示，提示该网站证书非法，继续访问存在安全风险

浏览器上面还会有一个按钮"继续访问"，技术再怎么牛逼保证安全，也担不住用户犯蠢去点击。

HTTPS传输过程

客户端先从服务器获取到证书，证书中包含了公钥
客户端对证书进行校验
客户端生成了一个对称密钥，使用公钥对对称密钥进行加密，发送给服务器
服务器得到这个请求之后，使用私钥解密，得到对称密钥
客户端发出后续的请求，后续的请求都是使用这个对称密钥加密的
收到的数据也都是使用这个对称密钥解密的

这个过程其实描述的是 SSL/TLS 的握手过程

但凡使用了SSL/TLS 的协议/工具/组件，都是类似的握手过程