以图文的方式解锁 HTTPS原理,10分钟还原HTTPS真相!架构师必读

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

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

以图文的方式解锁 HTTPS原理,10分钟还原HTTPS真像!架构师必读

如果我们要实现这个聊天软件,本文只考虑安全性问题,要实现:

A发给B的hello消息包,即使被中间人拦截到了,也无法得知消息的内容

如何做到真正的安全?

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

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

我个人的理解是:

A与B通信的内容,有且只有A和B有能力看到通信的真正内容

好,问题域已经定义好了(现实中当然不止这一种定义)。对于解决方案,很容易就想到了对消息进行加密。

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

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

以图文的方式解锁 HTTPS原理,10分钟还原HTTPS真像!架构师必读

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

只要这个密钥S不公开给第三者,同时密钥S足够安全,我们就解决了我们一开始所定问题域了。因为世界上有且只有A与B知道如何加密和解密他们之间的消息。

但是,在WWW环境下,我们的Web服务器的通信模型没有这么简单:

以图文的方式解锁 HTTPS原理,10分钟还原HTTPS真像!架构师必读

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

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

以图文的方式解锁 HTTPS原理,10分钟还原HTTPS真像!架构师必读

如何确定对称加密算法

慢着,另一个问题来了,我们的服务器端怎么告诉客户端该使用哪种对称加密算法?

当然是通过协商。

以图文的方式解锁 HTTPS原理,10分钟还原HTTPS真像!架构师必读

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

如何对协商过程进行加密

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

以图文的方式解锁 HTTPS原理,10分钟还原HTTPS真像!架构师必读

虽然服务器端向A、B……的方向还是不安全的,但是至少A、B向服务器端方向是安全的。

好了,如何协商加密算法的问题,我们解决了:使用非对称加密算法进行对称加密算法协商过程。

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

协商什么加密算法

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

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

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

如何得到公钥?

细心的人可能已经注意到了如果使用非对称加密算法,我们的客户端A,B需要一开始就持有公钥,要不没法开展加密行为啊。

这下,我们又遇到新问题了,如何让A、B客户端安全地得到公钥?

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

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

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

我们选择方案1,因为方案2又多了一次请求,还要另外处理公钥的放置问题。

公钥被调包了怎么办?又是一个鸡生蛋蛋生鸡问题?

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

我画了张图方便理解:

以图文的方式解锁 HTTPS原理,10分钟还原HTTPS真像!架构师必读

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

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

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

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

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

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

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

下图就是我们设计的第一版“数字证书”,证书中只有服务器交给第三方机构的公钥,而且这个公钥被第三方机构的私钥加密了:

上一篇 :《腾讯区块链方案白皮书》发布(附完整版pdf下载)

下一篇 :自建ssr服务器教程,ShadowsocksR节点搭建教程


天下数据手机站 关于天下数据 联系我们 诚聘英才 付款方式 帮助中心 网站备案 解决方案 域名注册 网站地图

天下数据18年专注海外香港服务器、美国服务器、海外云主机、海外vps主机租用托管以及服务器解决方案-做天下最好的IDC服务商

《中华人民共和国增值电信业务经营许可证》 ISP证:粤ICP备07026347号

朗信天下发展有限公司(控股)深圳市朗玥科技有限公司(运营)联合版权

深圳总部:中国.深圳市南山区深圳国际创新谷6栋B座10层 香港总部:香港上環蘇杭街49-51號建安商業大廈7樓

7×24小时服务热线:4006388808香港服务电话:+852 67031102

本网站的域名注册业务代理北京新网数码信息技术有限公司的产品

工商网监图标