🔎加密
- 加密
- 对称加密
- 非对称加密
对称加密🍭
只需要一个密钥(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
游戏结束
一山更比一山高(引入证书)
如何才能规避上述问题呢?
引入证书
上述问题的关键在于客户端并不能区分是服务器生成的 Pub 还是黑客伪装成服务器生成的 Pub1
证书的引入可以让客户端辨别是否为服务器生成的 Pub
密钥🍭
引入证书后, 共计 5 把密钥
证书🍭
服务器向权威机构申请证书
- 证书包括
- 服务器的 URL
- 证书的过期时间
- 证书的颁布机构
服务器生成的公钥(Pub)- …
加密后的签名
可以将加密后的签名看作是校验和
- 加密后的签名
- 根据证书的其他属性计算得出签名
- 证书的颁布机构利用自己的私钥(Pri2) 针对签名进行加密
如果数据(证书中的内容)相同, 按照相同的算法计算得到的签名也相同
如果签名不同, 则表示数据(证书中的内容)不同, 证书被修改
执行流程🍭
客户端向服务器索要证书
服务器给予客户端证书
注意
权威机构的公钥(Pub2)是每个系统自带的
客户端拿到证书后, 首先对证书进行 “校验”
- 客户端利用公钥(Pub2)对证书的加密签名解密, 得到结果 sum1
- 客户端计算证书中除加密签名之外的属性值, 得到结果 sum2
- 对比 sum1, sum2
如果结果相同, 表示证书未被修改
如果结果不同, 表示证书被修改
可能的疑问🍭
为何引入证书黑客便无法篡改信息
- 黑客篡改信息, 需要执行
- 将证书中的服务器公钥(Pub2)替换成自己的公钥(Pub1)
- 根据证书中的各个属性值, 重新计算出签名
需要对计算出的签名进行加密
对于最后一步, 黑客没有权威机构的私钥(Pri2), 也就无法对签名进行加密
你可能会说, 那为何黑客不伪造一个私钥进行加密
还记得前面提到过的每个系统内置了权威机构的公钥(Pub2)
公钥与私钥的关系是相匹配的
回忆前面说到的带锁的盒子与钥匙
黑客伪造的私钥与系统内置的公钥无法匹配
🔎结尾
创作不易,如果对您有帮助,希望您能点个免费的赞👍
大家有什么不太理解的，可以私信或者评论区留言，一起加油
