首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >看图学 HTTPS

看图学 HTTPS

作者头像
wangxl
发布2018-07-27 11:10:04
7040
发布2018-07-27 11:10:04
举报
文章被收录于专栏:PHP在线PHP在线
前言

之前说到HTTPS,在我的概念中就是更安全,需要服务器配置证书,但是到底什么是HTTPS,为什么会更安全,整套流程又是如何实现的,在脑子里没有具体的概念。所以,我花了几天的时间,通过参考一些文章,学习了HTTPS整套机制的实现,想要通过一篇文章把我学习到的东西总结出来,让更多之前不清楚HTTPS到底是什么的同学有一个入门的理解。

我看过的很多文章都是通过大量的文字和协议图来解释,但往往会让人感觉有点枯燥,这篇文章我会通过一幅幅流程图,形象的说明从HTTP到HTTPS的演变过程,让大家可以更容易理解一些。当然,这个只是入门级,如果想要学习更深入的HTTPS的知识,还是要深入到一个个协议里面,看一些大部头,才可以达到完全理解的效果。

本文也会同步到我的个人网站。

HTTP是什么样的?

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

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

加个密呢?

因为上图中数据是明文传输的,我们能想到最简单的提高安全性的方法就是在传输前对数据进行加密,如下图:

这种加密方式叫做:对称加密。加密和解密用同一个秘钥的加密方式叫做对称加密。

好了,我们对数据进行加密了,问题解决了吗?

多个客户端怎么办?

这是一个客户端,但是在WWW上,是成千上万的客户端,情况会怎样呢?

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

想一想,是不是还有别的办法呢?

相信大家都可以想到,如果对每一个客户端都用不同的秘钥进行传输是不是就解决这个问题了:

对称加密秘钥如何传输?

我们对每个客户端应用不同的对称加密秘钥,那么这个秘钥客户端或者服务端是如何知道的呢,只能是在一端生成一个秘钥,然后通过HTTP传输给另一端:

那么这个传输秘钥的过程,又如何保证加密?如果被中间人拦截,秘钥也会被获取。也许你会说,对秘钥再进行加密,那又如何保证对秘钥加密的过程,是加密的呢?

好像我们走入了 while(1),出不来了。

非对称加密

在对称加密的路上走不通了,我们换个思路,还有一种加密方式叫非对称加密,比如RSA。

非对称加密会有一对秘钥:公钥私钥。公钥加密的内容,只有私钥可以解开,私钥加密的内容,所有的公钥都可以解开(当然是指和秘钥是一对的公钥)。

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

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

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

MITM:Man-in-the-MiddleAttack

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

第三方认证

公钥被掉包,是因为客户端无法分辨传回公钥的到底是中间人,还是服务器,这也是密码学中的身份验证问题。

在HTTPS中,使用 证书 + 数字签名 来解决这个问题。

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

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

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

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

为什么要有签名?

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

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

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

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

对称加密

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

整体流程图
HTTPS = HTTP + TLS/SSL

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

总结

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

参考文章
  • https://en.wikipedia.org/wiki/HTTPS
  • https://www.instantssl.com/https-tutorials/what-is-https.html
  • https://tasaid.com/blog/20161003001126.html
  • https://www.west.cn/faq/list.asp?unid=1346
  • https://www.cnblogs.com/zhangshitong/p/6478721.html
  • https://www.wired.com/2016/04/hacker-lexicon-what-is-https-encryption/

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2018-06-01,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 php 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 前言
  • HTTP是什么样的?
  • 加个密呢?
  • 多个客户端怎么办?
  • 对称加密秘钥如何传输?
  • 非对称加密
  • 第三方认证
  • 为什么要有签名?
  • 对称加密
  • 整体流程图
  • 总结
  • 参考文章
相关产品与服务
多因子身份认证
多因子身份认证(Multi-factor Authentication Service,MFAS)的目的是建立一个多层次的防御体系,通过结合两种或三种认证因子(基于记忆的/基于持有物的/基于生物特征的认证因子)验证访问者的身份,使系统或资源更加安全。攻击者即使破解单一因子(如口令、人脸),应用的安全依然可以得到保障。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档