中间人攻击 http与https的区别

由一个视频引发的问题 https://v.douyin.com/iJJ9n2r7/ 中间人攻击

 

 

由于HTTP本身不具备加密的功能，所以也无法做到对通信整体（使用HTTP协议通信的请求和相应的内容）进行加密，即HTTP报文使用明文（未经过加密的报文）方式发送。

（对应于信件使用的文字不加密）

抓包：可以得到cookie

 

 

解决：采用加密技术

 

不验证通信方的身份，遭到伪装（信使装成邻居获取信息）：

HTTP协议的实现本身非常简单，不论是谁发送过来的请求都会返回响应，因此不确认通信方，会存在以下各种隐患。

• 无法确定请求发送至目标的Web服务器是否是真实意图返回响应的那台服务器，有可能是已伪装的Web服务器。
• 无法确定响应返回到的客户端是否是按真实意图接受响应的那个客户端，有可能是已伪装的客户端。

 

• 解决：消息认证码或者数字签名

• 3. 无法证明报文的完整性，可能已遭篡改

• 所谓完整性是指信息的准确度，也就意味着无法判断信息是否准确。

• 接收到的内容可能有误：

  由于HTTP协议无法证明通信的报文完整性，因此，在请求或响应送出之后直到对方接受之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉。

• 

   

  解决：消息认证码或者数字签名

• 共有密钥加密（对称加密）：

  优点：加密解密快

  共有密钥加密的一些计算方法：常用“AES”方法，

  还有凯撒密码——将报文字母向后移两位（“A”——“C”）等，易被暴力破解（将25种偏移都试一遍），DES

  DES、AES：算法略，后面再深入学习

• 

   

  

   

  问题在于：需要一种方法来安全地传送密钥——“钥匙交付问题”

  两种解决方案：

  1、使用公开的密钥加密的方法

  2、使用密钥交换协议

  公开密钥加密：

  两个密钥，一个用于加密，一个用于解密，用于加密的称为“公开密钥”，用于解谜的密钥称为“私有密钥”

  公开密钥加密计算方法的事例：RSA加密算法，椭圆曲线密码学（算法略）

• B先给自己的钥匙配很多把锁（公钥），再把锁发在网络上，此时的A就得到了B的锁，A将用公钥加密后的密文发给B，B使用私钥解密从A方收到的密文

• 

   

  由于公开密钥和密文都是通过互联网发送的，他们可能会被恶意的第三方窃取，但是由于密文不能解密，所以X方无法获取原始数据，相当于打不开带锁的箱子

• 

   优点：可以多个人同时给B发信息，B也不需要为每一个发信息的人制造一个新的锁

• 

   

• 但是这个加密真的没有问题吗？第一个问题是加密解密都需要时间，因此它不适合来回交换少量数据

  解决方法——“混合加密”

  混合加密：将上面两种加密结合起来

  在共有密钥加密（对称加密）中的问题是无法将密钥发送给B，为了解决这个问题，可以采用公开密钥加密（非对称加密）发送密钥，后面的加密解密过程都采用对称加密。也就是混合加密只在刚开始时用了一次非对称加密，速度变快。

• 

   

  第二个问题是，公开密钥的可靠性

  就像视频里的邮差一样，他将自己的锁冒充邻居的锁

• 

   

  

   

  由于公开密钥本身无法指示谁创建了它，因此A误以为这是B的公开密钥，所以A使用X的公开密钥进行加密，当A将密文发送给B的时候，X收到密文

  

   

  X使用自己的私有密钥来解密数据

  为了不被B发现数据已经被窃取，X使用B的公开密钥来加密数据，再将加密后的数据发送给B，B使用自己的私有密钥进行解密，由于B能解密密文所以B不会发现数据已经被窃取过。

  

   

  为什么无法通过公钥计算出私钥？如何制作出一对公钥和私钥？

  【数学不好也能听懂的算法 - RSA加密和解密原理和过程】 https://www.bilibili.com/video/BV1XP4y1A7Ui/?share_source=copy_web&vd_source=7a6d6fed0994f42fb1130eb617091779

• 回到那个问题：

• 

  解决方法：数字证书

  我们可以在B的公钥上面做一个标记确保这个锁是B的，没有被换过。

  可以颁发一个证书，证明这就是B

  

•  

  B需要值得信赖的第三方认证机构（CA）颁发一个证书，证明他们是公有密钥（PA）的所有者

  具体过程后面补充。

  图源：算法动画图解，《图解http》

  下期预告：

  HTTPS：HTTPS 是用来解决 HTTP 明文协议的缺陷，在 HTTP 的基础上加入 SSL/TLS 协议