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的加密方式超详细解读
在了解https的加密方式之前,我们需要先行了解两个特别经典的传统加密方式,以此开始我们今天的学习之旅途. 1.对称加密 1.1.定义需要对加密和解密使用相同密钥的加密算法.所谓对称,就是采用这种加 ...
【计算机网络】聊一聊https的加密方式
一.写在前面老是听见我的朋友讨论https的加密方式,讨论不一,最后查询资料后,给出我自己的理解当然了,这需要一定的网络安全方面的知识,如果你还不了解这些基础知识,建议看一下这两篇文章手
HTTPS —— HTTPS的加密方式
JavaEE传送门 JavaEE HTTP -- HTTP 协议中的细节(超详细!!) HTTP -- HTTP 响应详解, 构造 HTTP 请求目录 HTTPS "加密" 对称 ...
mysql 传输加密方式_请问各位大侠，要实现MYSQL加密传输，应该怎么做？
MYSQL加密传输应该怎么实现,有如下的操作步骤: To get secure connections to work with MySQL, you must do the following: I ...
[加密]账号登录密码传输加密
在实际使用过程中,用户登录时密码如果明文,存在被黑客窃取的高危风险.通过https传输加密和密码传输加密这两种方式,来防止账号登录过程的信息泄露风险. https加密是针对网站网址的,可以参考我的h ...
https 密钥 php,https加密方式是什么
Https加密介绍 Http直接通过明文在浏览器和服务器之间传递消息,容易被监听抓取到通信内容. Https采用对称加密和非对称加密结合的方式来进行通信. Https不是应用层的新协议,而是Http ...
简述https的几种加密方式
加密方式常见的加密方式:对称加密和非对称加密. 对称加密算法和非对称加密算法只不过是密码学中的两种加密算法罢了,所谓的算法就是一种可以将信息从一种形式转变为另一种形式的规则. 对称加密概念:对称密 ...
五千来多字，就为了聊聊HTTP报文，请求响应头，cookie以及HTTPS加密方式
靓仔靓女们大家好,我们又见面了,公众号:java小杰要加油,这周来分享一篇关于HTTP协议相关的文章看完此文可以对 HTTP报文格式.HTTP各种请求头,HTTP响应码. cookie属性以及HTT ...
HTTP和HTTPS的区别以及加密方式
目录基本区别 Http协议运行在TCP之上,明文传输,客户端与服务器端都无法验证对方的身份:Https是身披SSL(Secure Socket Layer)外壳的Http,运行于SSL上,SSL运行 ...

HTTPS传输加密方式

HTTPS传输加密方式相关推荐

最新文章

热门文章