其他分享
首页 > 其他分享> > HTTPS传输加密方式

HTTPS传输加密方式

作者:互联网

首先将HTTPS分为三层主干
第一层
第一层,就一句话,加密通信就是双方都持有一个对称加密的秘钥,然后就可以安全通信了,就这么简单。
至于这个密钥是什么?
1、可以是客户端自己想一个,然后传给服务端
2、也可以是服务端自己想一个,然后传给客户端
3、或者是双方都想一串字符,然后组合起来
这些都不重要,无论玩出多少花样,最终的目标都是,让双方协商出一个相同的秘钥,然后用它对称加密通信,就安全了。
第二层
这是才设计到非对称加密这个事情
非对称加密算法有两种方式,公钥加密私钥解密(这种方式为加密);私钥加密公钥解密(这种方式为认证)
此时我们需要的是第二种(认证)。
服务端把它的公钥明晃晃地扔给我,然后我用公钥把我要传给服务端的对称加密的秘钥,加密。
此时传递的就是加密的数据了,而且只能服务端用私钥才能解开,中间人无法得知。OK,这一步就是说,只要服务端成功把它的公钥扔给我,后面的事就顺理成章了。但是这一步公钥也是明文传输,但是相比一开始已经有了进步。因为秘钥传输既怕别人看到,也怕别人篡改。但此时的公钥已经不怕别人看到了,看到就看到呗,你知道公钥,也解不开客户端用公钥加密的秘钥。
但是,仍然怕篡改。
图片1. 由小宇设计一个双钥匙锁,配两把钥匙 C 和 D,然后把钥匙 D 给我。
2. 这个人没把钥匙 D 给我,而是把自己造的钥匙 Y 给了我,但我以为这是小宇给我的呢。
3. 我这边准备一个单钥匙锁,配一个钥匙 M,把它放在盒子里,用小宇给我的钥匙(其实是坏蛋给我的钥匙 Y)加锁,传给小宇。
4. 这个人收到加锁后的盒子,用自己的钥匙 X 轻松解了锁,因为这个锁是被 Y 锁的嘛~解锁后取出里面的钥匙 M,复制了一份,然后再用小宇的钥匙 D 加锁。
5. 小宇用 C 解开了锁,得到里面的钥匙 M,这个的确是我给的,但小宇不知道此时已经被坏人知道了,与此同时我也不知道这个事。
6. 于是我们用钥匙 M 加锁解锁通信,坏蛋也同样用钥匙 M 来偷窥或篡改我们的信息。
简单说,就是,我以为我是用小宇的钥匙加密,但却是坏蛋的。小宇以为是我用她的钥匙加密后传给她的 M,因为她解得开,但却是坏蛋伪装的。我们双方都不知情。

永远记住,你们的最终目标,就是协商出一个秘钥,来对称加密通信。而中间人的目标,也是要想办法知道你们的秘钥,其他的都不重要。永远别忘了最初的目标。
那么如何防止这个公钥被篡改,就是第三层了

第三层
我们先来举个例子,我们应该去找一个可信的人去做认证,也就是CA认证机构,我们先将它称为班长
我们思考如何做到,可以让中间人看到,到是无法篡改也就是说,坏蛋传给我假钥匙 Y,我可以知道这个是坏蛋的呢?只靠我们两个,几乎不可能,于是我求助了班长
我让班长也准备了一个双钥匙锁,然后配置了两把钥匙 J 和 K,然后把钥匙 K 公开让所所有人都知道。
小宇在第一次准备给我钥匙 D 时,不再直接给我了,而是找班长,把钥匙 D 放在一个盒子里,让班长用自己的钥匙 J 给加锁。
然后小宇把这个用钥匙 J 加好锁的盒子传给我,我用班长公开的钥匙 K 解锁盒子,就可以得到小宇的钥匙 D 了。
img
这样,中间的坏蛋可以用公开的钥匙 K 把盒子打开,看到小宇准备给我的钥匙 D。但是,他们却无法把自己伪造的钥匙 Y 传给我,因为要想加锁这个盒子,必须有钥匙 J 才行,而钥匙 J 只有班长知道。也就是说,目前这个内容,中间的坏蛋们只能看,不能修改了!如果不能修改,我就能成功用小宇给我的真正的钥匙 D 加锁我们之后要通讯用的钥匙 M,于是这个钥匙 M 就被安全地传给了小宇,我们之后就可以用这个谁也不知道的钥匙 M,和配套的单钥匙锁,愉快地聊天了!可是如果班长同坏蛋勾结,把 J 泄漏或者卖给了坏蛋怎么办呢?那没辙,说明他不配当班长
总结以下第三层:
我可以先自己生成一对公私钥,然后把公钥给服务端服务端用我的公钥给它的公钥加密,这就没法篡改了,甚至中间人连公钥是啥都不知道了,完美。可是我给服务端公钥的过程又变成明文了,又容易被篡改,那怎么办呢?那可以服务端给我公钥,然后我用这个公钥加密我的公钥传给服务端。那服务端给我公钥又是明文,又容易被篡改。永远有那么第一次的明文内容,会被中间人篡改。怎么消除这个第一次明文的尴尬呢?
CA 机构。CA 机构那边也有一套公私钥。服务端把自己的公钥给 CA,让 CA 用 CA 的私钥加密,然后返回加密结果。然后这个加密结果,可以用 CA 的公钥解,谁都可以解开。但是,如果要篡改结果,必须再次用 CA 的私钥加密,可是这个做不到,只要 CA 不是坏蛋即可。这就做到了第一次的明文传输的公钥,只能被看,无法被篡改。于是中间人就只能眼睁睁看着一个自己知道的公钥,从服务端传给客户端。然后客户端用这个公钥,给之后对称加密的秘钥加密,传给服务端,中间人由于不知道服务端私钥,解不开。于是,客户端和服务端,有了一个中间人不知道的,解不开的对称秘钥。之后就 OK 了。
图片
我们通常也可以在网页部分去查看证书的详细情况,来帮助自己进一步了解HTTPS传输加密认证
在这里插入图片描述
在这里插入图片描述

标签:公钥,加密,小宇,传输,钥匙,HTTPS,坏蛋,服务端
来源: https://blog.csdn.net/m0_53067332/article/details/122387547