Https详解

http存在的隐患

HTTP是属于应用层的协议,它是基于TCP/IP的,所以它只是规定一些要传输的内容,以及头部信息,然后通过TCP协议进行传输,依靠IP协议进行寻址,通过一幅最简单的图来描述:

Https详解

客户端发出请求,服务端进行响应,就是这么简单。在整个过程中,没有任何加密的东西,所以它是不安全的,中间人可以进行拦截,获取传输和响应的数据,造成数据泄露。

对称加密

对于这种情况,我们想到的最直接的办法就是对数据加密

Https详解

这种加密方式叫做:对称加密。 加密和解密用同一个秘钥的加密方式叫做对称加密。但是对称加密却解决不了任何问题,比如多个客户端怎么办?

Https详解

为所有的客户端都应用同一个秘钥A,这种方式很显然是不合理的,破解了一个用户,所有的用户信息都会被盗取。

但是如果每个客户端 都准备一个密钥也不是很现实,服务端需要维护的太多。

另外对称加密还存在一个问题就是对称加密的秘钥也需要传输,如果在传输秘钥的过程中被拦截,秘钥也会被获取,也是非常不安全的。

非对称加密

在对称加密的路上走不通了,我们换个思路,还有一种加密方式叫非对称加密,比如RSA。 非对称加密会有一对秘钥:公钥和私钥。 公钥加密的内容,只有私钥可以解开,私钥加密的内容,所有的公钥都可以解开(当然是指和秘钥是一对的公钥)。

Https详解

私钥只保存在服务器端,公钥可以发送给所有的客户端。

在传输公钥的过程中,肯定也会有被中间人获取的风险,但在目前的情况下,至少可以保证客户端通过公钥加密的内容,中间人是无法破解的,因为私钥只保存在服务器端,只有私钥可以破解公钥加密的内容。

现在我们还存在一个问题,如果公钥被中间人拿到篡改呢: MITM:Man-in-the-MiddleAttack

Https详解

客户端拿到的公钥是假的,如何解决这个问题?

第三方认证

公钥被掉包,是因为客户端无法分辨传回公钥的到底是中间人,还是服务器,这也是密码学中的身份验证问题。 在HTTPS中,使用 证书 + 数字签名 来解决这个问题。

Https详解

这里假设加密方式是MD5,将网站的信息加密后通过第三方机构的私钥再次进行加密,生成数字签名。

数字证书 = 网站信息 + 数字签名

假如中间人拦截后把服务器的公钥替换为自己的公钥,因为数字签名的存在,会导致客户端验证签名不匹配,这样就防止了中间人替换公钥的问题。

Https详解

浏览器安装后会内置一些权威第三方认证机构的公钥,比如VeriSign、Symantec以及GlobalSign等等,验证签名的时候直接就从本地拿到相应第三方机构的公钥,对私钥加密后的数字签名进行解密得到真正的签名,然后客户端利用签名生成规则进行签名生成,看两个签名是否匹配,如果匹配认证通过,不匹配则获取证书失败。

为什么要有签名?

大家可以想一下,为什么要有数字签名这个东西呢?

第三方认证机构是一个开放的平台,我们可以去申请,中间人也可以去申请呀:

Https详解

如果没有签名,只对网站信息进行第三方机构私钥加密的话,会存在下面的问题:

Https详解

因为没有认证,所以中间人也向第三方认证机构进行申请,然后拦截后把所有的信息都替换成自己的,客户端仍然可以解密,并且无法判断这是服务器的还是中间人的,最后造成数据泄露。

对称加密

在安全的拿到服务器的公钥之后,客户端会随机生成一个对称秘钥,使用服务器公钥加密,传输给服务端,此后,相关的 Application Data 就通过这个随机生成的对称秘钥进行加密/解密,服务器也通过该对称秘钥进行解密/加密:

Https详解

整体流程图

HTTPS = HTTP + TLS/SSL

Https详解

HTTPS中具体的内容还有很多,可以通过下图做一个参考:

Https详解

总结

HTTPS就是使用SSL/TLS协议进行加密传输,让客户端拿到服务器的公钥,然后客户端随机生成一个对称加密的秘钥,使用公钥加密,传输给服务端,后续的所有信息都通过该对称秘钥进行加密解密,完成整个HTTPS的流程。

好啦!今天分享到这里就结束了,希望大家持续关注马哥教育官网,每天都会有大量优质内容与大家分享!声明:文章转载于网络,版权归原作者所有,如有侵权请及时联系删除!

相关新闻

历经多年发展,已成为国内好评如潮的Linux云计算运维、SRE、Devops、网络安全、云原生、Go、Python开发专业人才培训机构!