比尔云BierYun--阿里云最新优惠活动
阿里云优惠码丨阿里云代金券

揭开HTTPS的神秘面纱

揭开HTTPS的神秘面纱

在说HTTP前,一定要先介绍一下HTTP,这家伙应该不用过多说明了,大家每天都在用,每一次HTTP请求,都是一次TCP连接。遗憾的是,请求的内容在TCP报文中是明文传输的,任何人截取到请求都可以读取其中的内容,很尴尬。

数据加密

为了防止请求内容被人窃取,在网络传输的路上我们做不了手脚,那就只能对传输的数据报文上做手脚了。对报文内容进行加密就是其中的一种方法。

有一种加密算法叫做对称加密算法,即加密和解密使用同一个秘钥,使用这种算法对请求数据进行加密,中间人因为没有秘钥,无法读取其中的内容。但是,使用这种算法进行加密,肯定要同意秘钥,那秘钥在网络中传输同样存在被窃取的风险啊。

这时,出现了新的加密算法:非对称加密算法,它有两把钥匙,一把叫私钥,是只有自己知道的,另一个叫公钥,可以发到互联网山,随便谁都可以看到,也就是说,传输过程中即使被别人看到也无所谓。这时,A向B发消息时,可以先用B的公钥对数据进行加密,B收到消息后再使用自己的私钥进行解密,中间即使被窃取了,因为没有对应的秘钥,也无法对了数据进行解密。

但是,非对称加密算法要比对称加密算法慢上许多。一个折中的办法,先使用非对称加密算法来传输对称加密的秘钥,以确保秘钥安全送达,之后就可以使用对称加密算法来加密数据报文了。

中间人劫持

你以为现在可以高枕无忧了吗?你以为你可以放心安全的进行通信了吗?天真。

假设,你现在正在和A通信,来自灵魂的拷问:你怎么能确定和你通信的人是A呢?

我们假设,通信正常进行。在通信开始传输公钥的时候,请求被中间人C劫持了。C讲A的公钥换成自己的公钥发给了你,在你发送请求后,再讲你的信息解密,使用A的公钥进行加密,发送给A。这样,在你和A看来好像是在和彼此通信,其实所有的信息都经过了C,所有的信息都被C一览无余。

那么如何保证收到的公钥是A的呢?完犊子了,又回到开始的问题了,如何保证秘钥在网络中安全的传输。但这次,加密似乎救不了我们了,我们必须要确保收到的秘钥确实是A发来的,也就是说报文没有别中途篡改过。

数字证书

其实无法保证报文内容的关键,在于我们对于收到的公钥无法确定有没有被人修改过,那如果有一个我们信任的中间人S来传输这个公钥就可以了。问题来了,D的公钥传输中同样存在被修改的问题,拿到再找其他人来传输S的公钥么?这要下去简直没完没了,完全就是三次握手的翻版。

问题的根源是什么?我们没有一个可以信任的公钥,那么解决办法也很粗暴,我们在本地保存一个绝对信任的公钥,它不是通过互联网来获取的,而是预装在系统中的,也就是系统/浏览器预置的顶层CA证书。

这些预装信任的内容,就是CA证书。通过CA获取A的公钥时,获得的数字证书大概长这样:

当收到证书后,我们对信息通过童谣的hash算法计算出信息摘要,在用CA的公钥对数字签名进行解密,若解密后的信息摘要与我们计算的摘要相同,则可以认为信息没有被人修改过。验证流程如下:

难道这样就不拍别人篡改了么?不怕。因为我们已经拿到CA的公钥了,这是没有问题的。中间人因为没有CA的私钥,及时截取到信息,也无法对修改后的内容进行加密并生成对应的数字签名。

这样一来,信息的传输问题算是暂时告一段落了。(不知道什么时候就冒出了新的安全问题,毕竟道高一尺魔高一丈)

HTTPS

到这里,HTTPS介绍完毕,以上大概就是HTTPS的全部内容了。HTTPS的一次请求,大概流程如下:

  1. 浏览器发出HTTPS请求
  2. 服务器讲自己的数字证书返回
  3. 浏览器用预置的CA来验证证书,若没有问题,顺利拿到公钥
  4. 浏览器生成对称加密算法的秘钥,通过服务器的公钥进行加密,将报文发送给服务器
  5. 服务器用自己的私钥进行解密,得到对称加密的秘钥
  6. 可以开始用获得的对称加密秘钥进行通信了

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

强烈推荐

高性能SSD云服务器ECS抗攻击,高可用云数据库RDS