🔎加密

加密
- 对称加密
- 非对称加密

对称加密🍭

只需要一个密钥(Key)

明文 + Key = 密文(明文与密钥结合, 通过加密手段变成密文)
密文 + Key = 明文(密文与密钥结合, 通过解密手段变成明文)

在这里插入图片描述

非对称加密🍭

需要两个密钥
一个是公钥(Pub)
一个是私钥(Pri)

明文 + Pub = 密文(明文与公钥结合, 通过加密手段变成密文)
密文 + Pri = 明文(密文与私钥结合, 通过解密手段变成明文)

在这里插入图片描述

🔎HTTPS的基本工作过程

使用对称加密

在这里插入图片描述

服务器对应的客户端有很多个
不同的客户端使用的密钥不同

如果全部的客户端都使用相同的对称密钥
那么黑客也可以伪装成客户端来获取对称密钥
(拿到对称密钥的黑客可以篡改信息…)

在这里插入图片描述
既然不同的客户端对应不同的对称密钥
因此就让客户端连接服务器时先自行生成一个对称密钥

那么生成好对称密钥的客户端该如何让服务器获取到对应的对称密钥呢?
网络传输

在这里插入图片描述

客户端生成对称密钥后, 将 Key 通过网络传输给服务器
但是这个数据有可能被黑客截获, 黑客也就知道了对称密钥
密文传输也就变成了明文传输

🍭那么如何解决上面的问题呢?

首先排除针对 Key 进行加密
如果针对 Key 进行加密, 就需要生成一个 Key1, 此时也需要将 Key1 通过网络传输给服务器
继续为 Key1 进行加密, 生成一个 Key2, 此时也需要将 Key2 通过网络传输给服务器
…
这样就陷入了死循环

解决方案
引入非对称加密

引入非对称加密

通过服务器生成的公钥(Pub)和私钥(Pri)
针对客户端生成的对称密钥(Key)进行加密与解密

公钥和私钥是两个比较大的整数
这两个整数, 任意一个作为公钥, 另一个作为私钥

在这里插入图片描述

流程分析🍭

客户端向服务器索要公钥(Pub)对对称密钥(Key)进行加密
服务器收到客户端的请求后返回 Pub 给客户端
客户端利用 Pub 对 Key 进行加密并发送给服务器
黑客截获到带有 Pub 的 Key(加密后的 Key), 但因为没有与 Pub 匹配的私钥(Pri), 因此无法进行解密
服务器成功收到 Pub 加密后的 Key, 并用 Pri 进行解密

当客户端成功将 Key 发送到服务器之后
依旧使用对称加密方式
非对称加密的引入是为了将 Key 发送给客户端

为何不依旧引入非对称加密🍭

对称加密速度快, 成本低
服务器拿到 Key, 黑客并未拿到 Key, 也就无法对 Key 所加密的数据进行篡改…
(将 Pub 理解成一个带锁的盒子, 盒子里面装着 Key, 打开盒子需要 Pri, 而 Pri 只有服务器拥有, 黑客并没有 Pri)

在这里插入图片描述

后续传输过程🍭

在这里插入图片描述

黑客的反制(中间人攻击)

黑客伪装成服务器生成公钥(Pub1)和私钥(Pri1)
当客户端向服务器索要公钥(Pub) 时, 将自己生成的 Pub1 发送给服务器
在这里插入图片描述

客户端使用 Pub1 对 Key 进行加密并返回给客户端
黑客截获到 Pub1 加密后的 Key, 并利用自己生成的 Pri1 对 Pub1 进行解密
解密完成, 黑客获取到了 Key
黑客将获取到的 Key 通过服务器生成的公钥(Pub) 进行加密
服务器收到 Pub 加密后的 Key 并利用 Pri 进行解密
解密结束后告知客户端 “成功收到Key”

解释🍭

将 Pub 看作是带有锁的盒子, Key 是需要存放在盒子中的内容, Pri 则是打开 Pub 这个盒子的钥匙
黑客是想要获得 Key(盒子中的内容)的角色
游戏的过程是客户端需要让服务器拿到盒子中的内容, 并且不能让黑客拿到盒子中的内容

服务器向客户端发送 Pub(带锁的盒子), 客户端拿到Pub, 黑客也拿到了 Pub
但是黑客没有钥匙(Pri), 因此无法打开盒子
怎么办?
“偷梁换柱” — 黑客自己伪造了一个盒子(Pub1)并且黑客拥有这个盒子的钥匙(Pri1)
黑客将伪造的盒子发送给客户端
客户端看到盒子发送过来了, 就乖乖的将 Key 放入盒子中并发送给服务器
黑客截获到客户端发送的带有 Pub1 加密的 Key, 并利用 Pri1(Pub1 这个盒子的钥匙)对盒子进行解锁
黑客获取到了 Key

游戏结束

在这里插入图片描述