设为首页 - 加入收藏 黄南站长网 (http://www.0973zz.com)- 国内知名站长资讯网站,提供最新最全的站长资讯,创业经验,网站建设等!
热搜: 2019 3000 2018 只要
当前位置: 首页 > 运营中心 > 建站资源 > 策划 > 正文

也许,这样理解HTTPS更容易!

发布时间:2019-11-14 11:31 所属栏目:[策划] 来源:翟志军
导读:【线上直播】11月21日晚8点贝壳技术总监侯圣文《数据安全之数据库安全黄金法则》 本文尝试一步步还原HTTPS的设计过程,以理解为什么HTTPS最终会是这副模样。但是这并不代表HTTPS的真实设计过程。在阅读本文时,你可以尝试放下已有的对HTTPS的理解,这样更利
【线上直播】11月21日晚8点贝壳技术总监侯圣文《数据安全之数据库安全黄金法则》

也许,这样理解HTTPS更容易!

本文尝试一步步还原HTTPS的设计过程,以理解为什么HTTPS最终会是这副模样。但是这并不代表HTTPS的真实设计过程。在阅读本文时,你可以尝试放下已有的对HTTPS的理解,这样更利于“还原”过程。

我们先不了聊HTTP,HTTPS,我们先从一个聊天软件说起,我们要实现A能发一个hello消息给B:

也许,这样理解HTTPS更容易!

如果我们要实现这个聊天软件,本文只考虑安全性问题,要实现:A发给B的hello消息包,即使被中间人拦截到了,也无法得知消息的内容。

如何做到真正安全

这个问题,很多人马上就想到了各种加密算法,什么对称加密、非对称加密、DES、RSA、XX、噼里啪啦~

而我想说,加密算法只是解决方案,我们首先要做的是理解我们的问题域——什么是安全?

我个人的理解是:A与B通信的内容,有且只有A和B有能力看到通信的真正内容。好,问题域已经定义好了(现实中当然不止这一种定义)。对于解决方案,很容易就想到了对消息进行加密。

题外话,但是只有这一种方法吗?我看未必,说不定在将来会出现一种物质打破当前世界的通信假设,实现真正意义上的保密。

对于A与B这样的简单通信模型,我们很容易做出选择:

也许,这样理解HTTPS更容易!

这就是对称加密算法,其中图中的密钥S同时扮演加密和解密的角色。具体细节不是本文范畴。

只要这个密钥S不公开给第三者,同时密钥S足够安全,我们就解决了我们一开始所定问题域了。因为世界上有且只有A与B知道如何加密和解密他们之间的消息。但是,在WWW环境下,我们的Web服务器的通信模型没有这么简单:

也许,这样理解HTTPS更容易!

如果服务器端对所有的客户端通信都使用同样的对称加密算法,无异于没有加密。那怎么办呢?即能使用对称加密算法,又不公开密钥?请读者思考21秒钟。

答案是:Web服务器与每个客户端使用不同的对称加密算法:

也许,这样理解HTTPS更容易!

也许,这样理解HTTPS更容易!

但是,你协商的过程是没有加密的,还是会被中间人拦截。那我们再对这个协商过程进行对称加密就好了,那你对协商过程加密的加密还是没有加密,怎么办?再加密不就好了……好吧,进行鸡生蛋蛋生鸡的问题了。

如何对协商过程加密

新问题来了,如何对协商过程进行加密?密码学领域中,有一种称为“非对称加密”的加密算法,特点是私钥加密后的密文,只要是公钥,都可以解密,但是公钥加密后的密文,只有私钥可以解密。私钥只有一个人有,而公钥可以发给所有的人。

也许,这样理解HTTPS更容易!

虽然服务器端向A、B……的方向还是不安全的,但是至少A、B向服务器端方向是安全的。好了,如何协商加密算法的问题,我们解决了:使用非对称加密算法进行对称加密算法协商过程。

这下,你明白为什么HTTPS同时需要对称加密算法和非对称加密算法了吧?

协商什么加密算法

要达到Web服务器针对每个客户端使用不同的对称加密算法,同时,我们也不能让第三者知道这个对称加密算法是什么,怎么办?

使用随机数,就是使用随机数来生成对称加密算法。这样就可以做到服务器和客户端每次交互都是新的加密算法、只有在交互的那一刻才确定加密算法。

这下,你明白为什么HTTPS协议握手阶段会有这么多的随机数了吧。

如何得到公钥

细心的人可能已经注意到了如果使用非对称加密算法,我们的客户端A,B需要一开始就持有公钥,要不没法开展加密行为啊。这下,我们又遇到新问题了:如何让A、B客户端安全地得到公钥?

我能想到的方案只有这些:

1:服务器端将公钥发送给每一个客户端

2:服务器端将公钥放到一个远程服务器,客户端可以请求得到

我们选择方案1,因为方案2又多了一次请求,还要另外处理公钥的放置问题。公钥被调包了怎么办?又是一个鸡生蛋蛋生鸡问题?

但是方案1有个问题:如果服务器端发送公钥给客户端时,被中间人调包了,怎么办?

我画了张图方便理解:

也许,这样理解HTTPS更容易!

显然,让每个客户端的每个浏览器默认保存所有网站的公钥是不现实的。

使用第三方机构的公钥解决鸡生蛋蛋生鸡问题

公钥被调包的问题出现,是因为我们的客户端无法分辨返回公钥的人到底是中间人,还是真的服务器。这其实就是密码学中提的身份验证问题。

如果让你来解决,你怎么解决?如果你了解过HTTPS,会知道使用数字证书来解决。但是你想过证书的本质是什么么?请放下你对HTTPS已有的知识,自己尝试找到解决方案。

我是这样解决的。既然服务器需要将公钥传给客户端,这个过程本身是不安全,那么我们为什么不对这个过程本身再加密一次?可是,你是使用对称加密,还是非对称加密?这下好了,我感觉又进了鸡生蛋蛋生鸡问题了。

问题的难点是如果我们选择直接将公钥传递给客户端的方案,我们始终无法解决公钥传递被中间人调包的问题。

所以,我们不能直接将服务器的公钥传递给客户端,而是第三方机构使用它的私钥对我们的公钥进行加密后,再传给客户端。客户端再使用第三方机构的公钥进行解密。

【免责声明】本站内容转载自互联网,其相关言论仅代表作者个人观点绝非权威,不代表本站立场。如您发现内容存在版权问题,请提交相关链接至邮箱:bqsm@foxmail.com,我们将及时予以处理。

网友评论
推荐文章