都说https安全 那为什么https安全,他解决了什么问题?

http为什么不安全

数据没有加密

  HTTP本身传递的就是明文,不会进行加密。只要可以截获传递的数据就可以获取内部的所有数据。在一个HTTP是基于TCP/IP实现的,而TCP/IP协议在网络传输过程中路由策略决定其数据会经过多个节点设备,每一个节点设备都可以很容易的获取明文数据,并且因为没有加密所以很容易可以理解其含义。

无法验证身份

  在使用http协议传输数据的时候,服务器和客户端都不能确认对方的身份,只要请求格式正确就可以交互。如果由中间节点将请求发送到其它的服务器上去,客户端也是不知道的。

数据容易被篡改

  一个请求是分为请求行、请求头和请求体的,只要结构正确,内部数据被修改客户端是无法知道的。比如,想数据流中加入一个广告,甚至于往其中加入一段恶意代码

https如何解决上述问题。为什么安全

1、解决数据加密问题

在这里插入图片描述

  首先加密算法可分为对称加密算法和非对称加密算法。区别是对称加密算法即可用于加密也可用于解密,非对称是有公钥和私钥,公钥用加密,私钥用于解密。
场景分析
  接下来场景分析:我们是用来网络传输的,所以收发双方都需要可以进行加密和解密,所以我们会想到使用对称加密算法。当我们使用了对称加密之后如果有人截获了我们的数据,因为已经使用了加密所以它根本无法获取到真正的数据。实现了数据保密。
  但是,大家想一下收发双方都需要知道对称加密算法是什么对吧,所以肯定是在数据传输之前先进行加密算法的沟通的。此时问题来了,如果中间人在此时截获了数据,也就知道了收发双方数据传输的加密算法是什么,那之后再进行的数据传输,即使使用了对称加密那对于那个中间人来说也相当于明文传输了。
在这里插入图片描述

  如何解决上面的问题呢?解决方法很玄妙。
需要非对称加密和对称加密结合使用。
  解决方案:由客户端发起请求,服务器接收到请求之后服务器生成一个公钥和对应的私钥,私钥自己留着将公钥发送给客户端,然后客户端使用发送过来的公钥将自己要使用的对称加密算法加密再发给服务器端,此时这个传输的对称加密算法只有服务器端可以解密,因为只有他自己有私钥。
在这里插入图片描述

2、解决无法验证身份问题

问题
  这个问题会带来什么安全问题?这不得不佩服那些黑客了,有很多天才。通过解决第一个问题,我们发现中间人即使截获了数据也没有任何作用,因为他没有最关键的私钥。此时他们就想办法了:我既然无法获取服务器的私钥,那我就自己造一个私钥,谁的公钥不是公钥呢是吧。
在这里插入图片描述
对上面的图进行讲解:
  中间人发现,截获了任何一个数据都无法进行解析了,所以他想到它可以伪装为服务器和客户端作为双方沟通的中转人。
  此时流程就变成了

  • 1:客户端向服务器端发送请求,中间人拦截到之后自己创造一个属于自己的公钥和私钥,然后将公钥发给客户端,并将请求放行发给真正的服务器,服务器接到请求后将真正的公钥发给客户端,但被中间人拦截。此时客户端拿到的是中间人的公钥,服务器的公钥被中间人拿到了。
  • 2:客户端将对称加密算法通过中间人的公钥加密后发送被中间人拦截。中间人使用私钥解密,再使用真正服务器的公钥进行加密并发送给服务器。此时中间人和服务器都知道了对称加密算法。
  • 3:之后服务器和客户端之间使用对称加密算法加密数据进行沟通,此时中间人拦截到请求后就可以获取所有的数据了。

解决方式
  服务器在发送公钥的时候需要CA证书一起发送到客户端。CA证书是什么?简单来说是个身份标识,由一个权威机构颁发,可查。这样中间人伪造的公钥客户端就能识别出来是假的了。

3、解决数据容易被篡改问题

问题
  到现在为止解决了数据保密问题,此时那个中间人又想了(并不是现在才开始想,可能一开始就想了),我要给你搞破坏,往你传输的数据中加入一段广告甚至恶意代码。
  这样的话,上面讲解的方式并不能发现这种事情。这就会导致客户端或者服务器处于危险之中。那如何解决呢?
解决
  解决上述问题可以通过数字签名,和CA证书完成。他们是干什么的呢?
   数字签名
   是发送方对发送的数据进行摘要后,对摘要使用自己的私钥进行加密后的数据。接收方的验证方式是:接收到数据后,对数据进行摘要,然后使用发送方的公钥对加密后的摘要进行解密,然后对比自己进行摘要得到的数据和解密后的摘要是否一致,如果一致也就说明数据是完整的没有被篡改的。
在这里插入图片描述
  但是此时问题再次出现,怎么验证A传递的 加密的摘要和公钥 确实是A传递的而不是被中间人修改过的?(此时就要使用CA证书)
  CA证书
   CA证书是由证书颁发机构颁发的证书,是A拿着自己的公钥私钥去证书颁发机构申请的能够标识自己身份的证书,证书中包含A的公钥和私钥还有CA的数字签名。CA的数字签名确保了别人不能伪造用户A的公钥和私钥。之后验证过程变为了:
在这里插入图片描述
其中增加了CA认证后,用户B就可以验证用户A发过来的公钥是否是正确的了。

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值