HTTPS 加密协议

✏️作者：银河罐头
📋系列专栏：JavaEE

🌲“种一棵树最好的时间是十年前，其次是现在”

HTTPS

http + 安全层 (SSL)

SSL 用来加密的协议，也叫 TLS

为啥要整个"安全层"呢？
原因是臭名昭著的"运营商劫持"(以前是用 http 明文传输)

网络上如果明文传输数据是非常危险的，就需要加密来保证安全。

“加密” 是什么

加密就是把 明文 (要传输的信息)进行一系列变换, 生成 密文。 解密就是把 密文 再进行一系列变换, 还原成 明文。在这个加密和解密的过程中, 往往需要一个或者多个中间的数据, 辅助进行这个过程, 这样的数据称为"密钥"。

HTTPS 的工作过程

HTTPS 其实主要是涉及到其中的 SSL 部分，SSL 并非仅仅是在 HTTPS 中使用。

进行安全传输，核心就是"加密"。

加密其中一种最简单有效的办法就是 “对称加密”。

• 对称加密

a(明文) + key => b(密文)

b(密文) + key => a(明文)

对称密钥：同一个密钥(key)，既可以用来加密，也可以用来解密。

对称加密的安全性的前提是：密钥不能被黑客知道。

密钥可以认为是一串数字/字符串，加密的过程，就是把明文和密钥进行一系列的数学变换(其中最简单的一种方式就是按位异或^)。

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

• 客户端生成密钥，还是服务器生成密钥呢？

由于一个服务器对应很多个客户端，每个客户端的密钥都不一样。假设客户端生成一个密钥，客户端就需要把这个密钥告知给服务器。

客户端生成密钥，发给服务器。因为此时服务器还不知道密钥，所以此处的密钥只能明文传输，密钥可能就被黑客给截获了。

以上问题的关键就是如何把密钥安全的传递过去。

此处就可以引入非对称加密。

• 非对称加密

生成一对密钥，公钥和私钥。

明文 + 公钥 => 密文

密文 + 私钥 => 明文

使用 公钥 加密，使用 私钥 解密(或者反过来也行)

服务器生成一对公钥私钥，客户端持有公钥，服务器持有私钥。此时客户端的公钥从服务器拿，黑客也能知道公钥。但是黑客不知道私钥，私钥是服务器持有的。

客户端使用公钥来对 对称密钥 进行加密，传输给服务器，服务器就可以拿着私钥来解密得到对称密钥。

此时客户端服务器就可使用这个对称密钥来进行后续的传输了。

• 为啥有了非对称加密，还要保留对称加密呢，全都用非对称加密行不行？

不行！

因为对称加密快，非对称加密慢，要尽可能的提高整体的速度。

但是上述过程中还存在一个问题。

• “中间人攻击”

• 如何避免"中间人攻击"？

解决中间人攻击的关键是，客户端能够辨别这个响应(公钥)是服务器真实的公钥

引入一个"证书"(本质上是引入第三方的公证机构)。

引入证书

服务器(网站)在设立之初，就需要去专门的认证机构，申请证书(提供一些资质的)。审核通过就会给你颁发证书。服务器生成的公钥就包含在这个证书当中了。

客户端向服务器申请公钥的时候，此时就不是单单申请一个公钥了，而是把整个 证书都请求过来。

客户端拿到证书之后，就可以对证书进行校验，(验证一下证书是不是假的，是不是被篡改的)。

如果发现证书无效，浏览器就会弹窗警告。

客户端拿到证书就可以对证书进行校验，证书上面会带有一个特定的字段，叫做证书的签名。

客户端对于证书的校验过程：

认证机构，也有一组公钥私钥(不是 pub1 pri1)，私钥用来加密 hash 值得到签名。公钥是客户端拥有的使用公钥解密签名得到hash 值。

• 黑客能否把证书篡改了？

比如把公钥给改了，一旦替换了公钥，此时客户端算的 hash2 和签名解密出来的 hash1 就对不上了，客户端就知道无效。

黑客不知道认证机构的私钥，即使黑客自己算好了新的篡改后的 hash 值，但是由于黑客不知道私钥就无法加密生成签名。