HTTPS怎么保证传输安全的?

Posted 2022-04-06 小智RE0

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了HTTPS怎么保证传输安全的?相关的知识，希望对你有一定的参考价值。

最近在B站看到一段关于HTTPS讲解的视频;感觉非常地通俗易懂;
【web安全3】【硬核】HTTPS原理全解析

自己也画图做了笔记,加深一下知识点的记忆

文章目录

HTTP : 超文本传输协议,采用明文传输的方式,不安全;

HTTPS:具有一定安全性的超文本传输协议,使用了加密算法;

作图推荐使用的工具: excalidraw在线作图;
本人也是第一次使用,没想到这个画图效果这么棒.

1.传统的http传输

比如模拟这个传统的http的数据传输.

2.对称加密

若是使用对称加密呢;

虽然说每次在传输中都将数据加密为 密文 X 保证安全;
但是由于服务端在提供加密使用的这个 K 时,无法确定一共有多少了客户端,不可能做到为每个客户端量身定做一个 加密使用的 K , 那么在这个交互的协议过程中使用的这个 k 都是同一个.
这么一分析的话,所有人公用这同一个k进行加密解密的处理,这样的加密和没有加密有什么区别呢?

3.非对称加密

再看看纯使用非对称加密的效果;

这个公钥加密,私钥解密, 或者[私钥解密,公钥解密] 的过程,理想情况下看起来比较完善;
但是这个公钥是开放给所有的客户端,那么假设中间人攻击,伪装成客户端索要到公钥,是不是就能顺利截获到传输的数据了呢

4.假设的 `对称加密结合非对称加密`

那么HTTPS的加密机制,实际就是结合了 对称加密和非对称加密.

先让当前的客户端和服务端通过 非对称加密算法 协商得出一个加密用的 key;
达成一致后, 两方采用对称加密算法 即可愉快地交互数据了.
实际之后的数据传输也完全可以用非对称加密,但是一方面是[非对称加密解密计算开销远大于对称加密],然后是出于安全性的做法.

首先看看自己假想状态下的 非对称加密混合对称加密协议;

可是,即使这样的混合加密手段, 中间人还能攻击!!!

比如说有这么一个神秘的中间人,拥有自己独特的公钥和私钥,暂且称为mid-pubKey和mid-selfKey;
(1) 首先中间人拦截客户端索要公钥的请求, 然后将自己的公钥mid-pubKey发给客户端;
(2)然后中间人假装为客户端,向服务器索要公钥, 得到pubKey存起来;
(3)此时客户端自己用mid-pubKey加密了num为X 发了出来,不幸的是有备中间人截获;
(4)中间人用自己的私钥mid-selfKey解密X得到 num;
(5)中间人用之前索要的服务端公钥 pubKey加密num为Y; 发给服务器;
(6) 服务器此时用自己的秘钥selfKey解密得到num;
(7)后面呢,中间人就像是一个中介, 收取真正的客户端和服务器交互的消息.

5.加入了CA机构的 `对称加密结合非对称加密`

那么,存在这个不友好的中间人,怎么安全地传输信息呢;

试试CA
CA是什么呢? ----> 点击此处查看百度百科:CA认证

证书颁发机构（CA, Certificate Authority）即颁发数字证书的机构。是负责发放和管理数字证书的权威机构，并作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。

由于之前中间人能完美无差地攻击,从一方面来看,因为 客户端无法辨认公钥是不是合法的;
那么CA权威机构,恰好可以解决这个问题;

简单分析一下;
(1)首先这样一个友好的CA机构出现了;它有着自己的公钥,私钥,暂且称为CA-pubKey,CA-selfKey;
(2)这次服务器不会那么直接了,他先去把自己的公钥交给CA机构, 那么CA机构就可以用自己的私钥CA-selfKey加密服务器的公钥pubKey,生成得到证书license; 颁发给服务器;
(3)这时客户端也聪明了,不要公钥,索要的是证书license;
(4)然后客户端在自己这里存了CA机构的公钥CA-pubKey,解密验证证书,得到服务端的公钥pubKey;
(5)然后就像之前那样,客户端可以加密一段字符串num,生成秘钥X,发给服务器;
(6)服务器用私钥selfKey解密X得到num;
(7)愉快对称加密交互…