HTTPS 协议的加密

HTTPS 协议的加密过程

众所周知, HTTP 的传输是明文传输, 传输过程中容易被 [ 坏人 ] “截胡” 获取数据, 甚至是篡改。
于是引入了 HTTPS, HTTPS 的加密也就是最核心的改进

对称加密

首先我们先了解一个概念

密钥 : 通俗来说就是 [ 用于加密解密的工具 ]

对称加密就是一个较为简单的加密方法, 就是通过一个 [ 密钥 ] 来进行加密和解密, 并且虽然加密简单, 但是效率很高

但是前面说到, 中间设备可能被 [坏人] 入侵, 那么 [ 密钥 ] 对于他们来说就不难获取, 那这就不行了, 还得改进

非对称加密

非对称加密的引入就是为了解决 [ 对称密钥 ] 容易被获取的情况, 用于保护 [ 对称密钥 ], 围绕着这个核心, 引入两个概念:

1. 公钥 : 公布出来的密钥, 所有人都能知道, 通常是 [ 信息发送方 ] 用 [ 公钥 ] 来加密
2. 私钥 : 由另一方拥有, 用于自己来解密, 通常是 [ 信息接收方 ] 用 [ 私钥 ] 来解密

这个机制很灵活, 带来了更高的安全性, 但是也带来了 [ 低效 ], 所以通常是通过 [ 非对称密钥 ] 来获取 [ 对称密钥 ], 这时候就只有交流双方才知道 [ 对称密钥 ], 交流双方再通过 [ 对称密钥 ] 进行信息交互

破绽

现在好了, 先通过双方的交流确定 [ 对称密钥 ]是个好方法, 但是也有破绽, 被称为 [ 中间人攻击 ]

Core: 我们记公钥为 A, 私钥为 B (配合图解食用), 服务器生成 [ 公钥 ] 和 [ 私钥 ] 后, 客户端会向服务器获取 [公钥], 然后中间设备收到服务器发来的 [ 公钥 ] 后, 假装自己是服务器, 生成自己的 [ 公钥 ] 和 [ 私钥 ], 客户端就会傻傻的用 [坏人] 的 [ 公钥] 去对 [ 对称密钥 ] 进行加密, 中间设备就得逞了, 于是就可以用自己的 [ 私钥 ] 就能获取 [ 对称密钥 ]

最后再装 [没事人] 用原来的公钥加密完发送服务器, 假装什么都没发生过

证书

我们发现, 这个破绽之所以能够是破绽, 关键就在于客户端上当受骗了, 把别人发给它的 [ 公钥 ] 当成真的 [ 公钥 ], 所以想要升级, 关键就在于 如何判断收到的公钥是服务器的, 于是引入 「证书」机制

我们在通信过程中引入一个「通信端」, 可以用来申请「证书」, 或者验证「证书」, 服务器可以带着公钥去「认证端」申请「证书」, 证书本质上是一个带有公钥, 服务器域名...等认证信息, 并且经过加密的字符串。
于是客户端在接收公钥的时候, 就可以申请获取「证书」, 并且可以将「证书」发送给「认证端」来验证

总结

总结一下, [ 对称密钥 ] 的实现很简单, 因此也十分高效, 通常用于大量信息的存储, [ 非对称密钥 ] 用来保护 [ 对称密钥 ] 不被获取, 比较低效。而在使用 [ 非对称密钥 ] 来统一 [ 对称密钥 ] 的时候, 由于客户端不具备判断公钥是否来自服务器的能力, 所以可能出现 [ 中间人攻击 ], 为了应对这种场景, 又引入了 [ 证书 ] 机制, [ 证书 ] 包含了 公钥, 服务器域名 等信息, [ 证书机构 ] 也可以对 [ 证书 ] 进行验证, 可以识别出内容是否被篡改等