https浅析

https浅析

 http协议本身有着很大的缺陷

 1. 通信使用明文,若被抓包,则直接被窃取信息




 2. 不验证与自身通信者的身份,有可能遭到伪装

 - 在数据传输的过程中,经过了某一计算机,该计算机直接响应你的请求,然后你无法判断这个请求是否为目标服务器返回的请求




 3. 无法证明报文是否被篡改


 - 在数据的请求响应过程中,经过某一计算机,该计算机将报文内容进行修改,而后让报文继续正常传输,然而我们无法判断报文在传输的过程中是否被篡改

 http的tcp连接的建立过程与https的tcp连接建立过程是不同的。后者还多了ssl连接,在这个过程中进行证书验证与加密模式的协商与传递。

 在讲https通信之前,我们先捋清楚对称加密与非对称加密,因为这两者是https通信加密的基理。

对称加密

对称加密会在建立tcp连接之后,共享秘钥,往后双方使用该秘钥加密报文,使得http报√文不再是明文。

 不过这存在一个问题,虽然报文被抓包时无法直接看到明文了,但如果同时抓包了秘钥,就可以被解密出来,那和明文就没有什么差别了。

非对称加密

 在对称加密中,双方通过一个秘钥加密和解密。那么如果我们把加密和解密分别用两个不同的秘钥来操作呢?

 这两个秘钥就是公钥及私钥。我们使用公钥加密报文,用私钥解密报文,是一对的。要想双向通信,则不管是服务器还是浏览器都需要创建出自己的一对秘钥(注意,客户端也能创建公钥私钥)。

 现在,我们以浏览器发送信息,服务器接受信息为例。即浏览器加密报文,服务器解密报文,也就是说,使用的是服务器的公钥与私钥。

 在建立tcp连接之后,服务器将公钥发送给客户端,往后客户端每次发送数据之前都是用该公钥加密,当服务器接受到加密后的报文后,使用与客户端加密数据的公钥相对应的私钥来进行解密。通信成功。

 他的安全之处在于:

 在报文的传输过程中,报文不是明文的。再进一步讲,就算报文被抓包了,且公钥也被抓包了,但因为能解密该公钥加密的报文的私钥只在对应的服务器里有,这个私钥是不会在网络中传输的,也就无法被抓包,那么劫持者也就无法解密该报文。也就无法获取到有效信息。

 大家可能会想:既然已经这么安全了,那么https协议就通过非对称加密来进行通信不就好了?

 之所以不这样做的原因是代价太大了,因为需要每次通信都用公钥进行一次加密,发送到对方,对方得先找到该公钥对应的私钥,然后再用该私钥解密。每次解密都是cpu计算的,若有大量的通信请求,则对于cpu负载太大了。

 我们再来说说CA证书,这也是https的关键。

CA证书

 CA证书是数字证书,是由CA机构颁发的,所有人都信任该机构,在服务器与客户端建立SSL连接时由服务端返回(当然,客户端也可以申请CA证书,在需要确认客户端的可靠性时这样做,例如银行ATM机信息查询及存取钱)。

 CA证书包括以下内容:

  • 证书的颁发机构
  • 版本证书的使用者
  • 证书的公钥(也就是说公钥是在CA证书中的)
  • 证书的有效时间
  • 证书的数字签名(Hash值)(其实是用证书的私钥进行加密后的值)
  • 签名Hash算法

解决http的缺陷

 了解了这些后,现在我们可以来一一解决http协议的缺陷了。

通信使用明文,若被抓包,则直接被窃取信息

 https协议是使用对称加密和非对称加密的组合加密,使得就算被抓包,也无法获得有效信息。这个我会在接下来梳理清楚。

不验证与自身通信者的身份,有可能遭到伪装

 要想解决这个问题,就得借助于CA证书了。

当浏览器端接受到服务器返回的CA证书时,他会进行一个验证操作——将该证书中的公钥与CA机构预置在操作系统中所有的公钥进行对比,如果没有找到相同的公钥,则证明该证书并非CA机构颁发的,所以有可能是伪装的服务器。

 我的理解是:你访问的网站是拥有CA证书的,所以其证书中的公钥应该能够被在操作系统中找到,而伪装者一般不会购买CA证书,最多只是自己创建了一个自己的证书(不会被CA机构承认),所以如果找不到该证书中的公钥的话,那就是伪装者。

无法证明报文是否被篡改

 同样得借助于CA证书。

 我们是通过证书中的公钥,证书的数字签名,签名Hash算法互相配合来做到是否篡改过该报文。

 过程如下:

在验证了通信者的身份不是伪装的之后,我们用证书的公钥解签证书的数字签名,得到摘要。然后我们用签名Hash算法解析证书的数字签名,又得到一个摘要。将这两个摘要进行对比,若相同,则报文未被篡改。若不同,则说明报文被篡改过,数据不安全。

 在这里我想多提一句:

 可能大家发现了,我说了这么一句话:“我们用证书的公钥解签证书的数字签名”,可是我之前又说了“我们使用公钥加密报文,用私钥解密报文”,这不是矛盾吗?

 当然不矛盾,一个是加密解密,一个是签名解签。

 大家可以这样记忆:

  1. 公钥加密,私钥解密。——用于加解密
  2. 私钥产生签名,公钥验签。——用于签名

https建立TCP连接流程

 以下讲的只是ssl连接过程,至于TCP连接3次握手过程忽略不讲。

 1. 客户端访问服务器,会发送客户端中产生的一个随机数A,将该随机数发送给服务器




 2. 服务器接收到信息之后,也生成一个随机数B,并将该随机数B和CA证书一同返回给客户端




 3. 客户端A接受到响应后,首先会验证该证书是否为合法CA证书,若合法,再通过验签操作确认该响应是否被篡改过(这两个过程都在上面讲过了,也就不在赘述)。若没有被篡改,则再产生一个随机数C,用证书的公钥来加密该随机数,并发送给服务器




 4. 服务器接受到数据后,使用私钥解密,得到真正的随机数C,这样不论是客户端还是服务器,都有随机数A,B,C,然后双方利用这三个随机数生成一个秘钥(服务器与客户端生成的秘钥是相同的,因为随机数都相同),而后通过这个生成的秘钥来进行对称加密来传输数据




 5. 之后所有的数据传输都是用该秘钥对称加密,回到了正常的http通信

 这个过程讲完了,我们回到第一个问题:“通信使用明文,若被抓包,则直接被窃取信息”。https不会出现这个情况,一是因为传输的数据不是明文,是对称加密后的数据。再是加密的秘钥并未在网络上传输过,是服务器和客户端根据本地随机数A,B,C生成的。所以可以保证即使被抓包了,攻击者也无法解析出有效信息。

 可能大家又会说,随机数A,B,C不是在网络上传输过了吗,那被抓包了,不就也可以用这三个随机数生成相同的秘钥吗?

 大家有没有注意到,虽然随机数A,B都是明文传输的,但随机数C他是使用的非对称传输,这也就是说,抓包者无法知道这个随机数C的真实值,即使他抓包到了公钥,但因为私钥只在服务器本地里,无法得到,所以也就无法解密出随机数C的真实值了。

(全文完)

参考资料

  1. HTTP加密解密过程:http://blog.sina.com.cn/s/blog_185268e880102xvvu.html
  2. 非对称加解密,私钥和公钥到底是谁来加密,谁来解密:https://blog.csdn.net/qq_23167527/article/details/80614454
  3. 一文读懂Https的安全性原理、数字证书、单项认证、双项认证等:https://www.cnblogs.com/imstudy/p/9001886.html
  4. https数字证书交换过程:https://blog.csdn.net/laiyuan999/article/details/80011579
  5. 我是这样理解HTTP和HTTPS区别的:https://www.cnblogs.com/jesse131/p/9080925.html
上一篇:awk 命令


下一篇:搞懂分布式技术9:Nginx负载均衡原理与实践