我们为什么要用HTTPS

2018/06/11

218

HTTP

HTTP 是一种超文本传输协议,它是无状态的、简单快速的、基于 TCP 的可靠传输协议。
HTTP 是明文传输的,这就造成了很大的安全隐患。在网络传输过程中,只要数据包被人劫持,那你就相当于赤身全裸的暴露在他人面前,毫无半点隐私可言。
想象一下,如果你连了一个不可信的 WIFI,正好有使用了某个支付软件进行了支付操作,那么你的密码可能就到别人手里去了,后果可想而知。

HTTP三大风险

  1. 窃听风险(eavesdropping):第三方可以获知通信内容。
  2. 篡改风险(tampering):第三方可以修改通信内容。
  3. 冒充风险(pretending):第三方可以冒充他人身份参与通信。

HTTPS

HTTPS解决了HTTP的三大风险

  1. 所有信息都是加密传播,第三方无法窃听。
  2. 具有校验机制,一旦被篡改,通信双方会立刻发现。
  3. 配备身份证书,防止身份被冒充。

HTTPS 是如何做到数据的加密传输

对称加密与非对称加密

对称加密:即通信双方通过相同的密钥进行信息的加解密。加解密速度快,但是安全性较差,如果其中一方泄露了密钥,那加密过程就会被人破解。

非对称加密:相比对称加密,它一般有公钥和私钥。公钥负责信息加密,私钥负责信息解密。两把密钥分别由发送双发各自保管,加解密过程需两把密钥共同完成。安全性更高,但同时计算量也比对称加密要大很多。

对于网络通信过程,在安全的前提下,还是需要保证响应速度。如何每次都进行非对称计算,通信过程势必会受影响。所以,人们希望的安全且快速传输,最终肯定是以对称加密的方式进行。如图:

首先 Session Key 是如何得到的,并且在 Session Key 之前的传输都是明文的。Session Key 通过网络传输肯定不安全,所以它一定各自加密生成的。因此在这之前,双方还要互通,确认加密的算法,并且各自添加随机数,提高安全性。如图:

这样双方确认了使用的 SSL/TLS 版本,以及生成 Session Key 的加密算法。并且双方拥有了2个随机数(客户端、服务端各自生成一个)。可是如果按照目前的随机参数,加上加密算法生成 Session Key 呢,还是存在风险,加密算法是有限固定的,而且随机数都是明文传输的,有被截获的可能。

让加密算法变得不可预测,可能性不大。那么能否再传输一个加密的随机数,这个随机数就算被截获,也无法破译。这就用到了非对称加密算法,我们在步骤二中,把公钥传输给客户端。这样客户端的第三个随机数用公钥加密,只有拥有私钥的服务端才能破译第三个参数,这样生成的 Session 就是安全的了。如图:

不容易啊,看似完成了。现在生成的 Session Key 是不可预测的(就算被截获也无所谓),我们可以放心的进行私密通信了。真的是这样吗?我们似乎对服务端给的公钥十分信任,如果你目前通信的本身就不可信,或者被中间人劫持,由它发送伪造的公钥给你,那后果可想而知,这就是传说中的“中间人攻击”。

所以,我们得包装一下公钥,让它变得安全。这就引出了数字证书的概念,数字证书由受信任的证书机构颁发,证书包含证书文件与证书私钥文件。私钥文件由服务端自己保存,证书文件发送给请求的客户端,文件包含了域名信息、公钥以及相应的校验码。客户可以根据得到的证书文件,校验证书是否可信。如图:

这下算简单讲完了整个的通信过程,首先在 TCP 三次握手后,进行非对称算法的加密(校验证书),将得到的参数进行加密生成会话所需的 Session Key,在之后的数据传输中,通过 Session Key 进行对称密码传输,会话信息在私密的通道下完成。

评论