标签：公钥 加密 小宇 传输 钥匙 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 了。
这样，中间的坏蛋可以用公开的钥匙 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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。