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 了。

这样，中间的坏蛋可以用公开的钥匙 K 把盒子打开，看到小宇准备给我的钥匙 D。但是，他们却无法把自己伪造的钥匙 Y 传给我，因为要想加锁这个盒子，必须有钥匙 J 才行，而钥匙 J 只有班长知道。也就是说，目前这个内容，中间的坏蛋们只能看，不能修改了！如果不能修改，我就能成功用小宇给我的真正的钥匙 D 加锁我们之后要通讯用的钥匙 M，于是这个钥匙 M 就被安全地传给了小宇，我们之后就可以用这个谁也不知道的钥匙 M，和配套的单钥匙锁，愉快地聊天了！可是如果班长同坏蛋勾结，把 J 泄漏或者卖给了坏蛋怎么办呢？那没辙，说明他不配当班长
总结以下第三层：
我可以先自己生成一对公私钥，然后把公钥给服务端，服务端用我的公钥给它的公钥加密，这就没法篡改了，甚至中间人连公钥是啥都不知道了，完美。可是我给服务端公钥的过程又变成明文了，又容易被篡改，那怎么办呢？那可以服务端给我公钥，然后我用这个公钥加密我的公钥传给服务端。那服务端给我公钥又是明文，又容易被篡改。永远有那么第一次的明文内容，会被中间人篡改。怎么消除这个第一次明文的尴尬呢？
CA 机构。CA 机构那边也有一套公私钥。服务端把自己的公钥给 CA，让 CA 用 CA 的私钥加密，然后返回加密结果。然后这个加密结果，可以用 CA 的公钥解，谁都可以解开。但是，如果要篡改结果，必须再次用 CA 的私钥加密，可是这个做不到，只要 CA 不是坏蛋即可。这就做到了第一次的明文传输的公钥，只能被看，无法被篡改。于是中间人就只能眼睁睁看着一个自己知道的公钥，从服务端传给客户端。然后客户端用这个公钥，给之后对称加密的秘钥加密，传给服务端，中间人由于不知道服务端私钥，解不开。于是，客户端和服务端，有了一个中间人不知道的，解不开的对称秘钥。之后就 OK 了。

我们通常也可以在网页部分去查看证书的详细情况，来帮助自己进一步了解HTTPS传输加密认证

这篇关于HTTPS传输加密方式的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！