假如这样来了解HTTPS,一篇就够了!

摘要:1、前言可能有初学者会问,即时通讯应使用的通信安全,不就是对Socket长连接进行SSL/TLS加密这些知识吗,干吗要了解HTTPS协议呢。这其实是个误会:当今主流的手机端IM数据通信,总结下来无外乎就是长连接+短连接的方式,长连接就是众所周之的TCP、UDP、WebSocket(WebSocket的

1、前言

可能有初学者会问,即时通讯应使用的通信安全,不就是对Socket长连接进行SSL/TLS加密这些知识吗,干吗要了解HTTPS协议呢。

这其实是个误会:当今主流的手机端IM数据通信,总结下来无外乎就是长连接+短连接的方式,长连接就是众所周之的TCP、UDP、WebSocket(WebSocket的本质还是TCP),而短连接就是HTTP/HTTPS了。即时通讯IM应使用中,短连接的安全跟长连接相比,同样很重要。市面上的主流短连接通信方式,都已逐渐从HTTP过渡到HTTPS了(iOS上的应使用就更彻底了,苹果直接强制要求用HTTPS协议,否则不允许上架APP Store,详见《苹果即将强制实施 ATS,你的APP准备好切换到HTTPS了吗?》。不过,鉴于多方面起因,苹果实际上延迟了ATS的强制执行,有兴趣可以到苹果官方理解)。

题外话:关于短连接、长连接的定义,微信是一个特例,微信在网络通信这一层做的比较彻底和极端,几乎再造了一套针对手机端IM的网络层框架(详见:《如约而至:微信自使用的手机端IM网络层跨平台组件库Mars已正式开源》),所以针对微信来说短连接可能并不能就是HTTP/HTTPS了。

总之,无论是即时通讯IM还是其它应使用,在移动网络日益发达的今天,安全显的尤为重要,HTTPS已经越来越普及,尽快拥抱它才是符合技术潮流的。

本文将尝试使用浅显易懂的语言,一步步复原HTTPS的设计过程,以便您能轻松了解为什么HTTPS最终会是这副模样。但鉴于HTTPS的复杂性,本文的文字主要是为了方便您的了解,而并不代表完全遵从HTTPS的真实设计过程。在阅读本文时,你可以尝试放下已有的对HTTPS的了解,这样更利于您“了解”这个过程和技术原理。

学习交流:

- 即时通讯开发交流3群:185926912[推荐]

- 手机端IM开发入门文章:《新手入门一篇就够:从零开发手机端IM》

(本文同步发布于:http://www.52im.net/thread-1890-1-1.html)

2、关于作者

翟志军,个人博客地址:https://showme.codes/,Github: zacker330。感谢作者的原创分享。

3、相关文章

要了解HTTPS,须对HTTP协议有所理解,以下文章可能是您需要的:

《网络编程懒人入门(七):深入浅出,全面了解HTTP协议》

《从HTTP/0.9到HTTP/2:一文读懂HTTP协议的历史演变和设计思路》

《脑残式网络编程入门(三):HTTP协议必知必会的少量知识》

《现代手机端网络短连接的优化手段总结:请求速度、弱网适应、安全保障》

《IM开发基础知识补课(四):正确了解HTTP短连接中的Cookie、Session和Token》

本文是IM通讯安全知识系列文章中的第7篇,此系列总目录如下:

《即时通讯安全篇(一):正确地了解和用Android端加密算法》

《即时通讯安全篇(二):讨论组合加密算法在IM中的应使用》

《即时通讯安全篇(三):常使用加解密算法与通讯安全讲解》

《即时通讯安全篇(四):实例分析Android中密钥硬编码的风险》

《即时通讯安全篇(五):对称加密技术在Android平台上的应使用实践》

《即时通讯安全篇(六):非对称加密技术的原理与应使用实践》

《即时通讯安全篇(七):假如这样来了解HTTPS原理,一篇就够了》(本文)

4、一个引子

我们先不了聊HTTP/HTTPS,我们先从一个IM聊天软件说起。

假设我们想要实现A能发一个hello消息给B:?

由于只是为了方便讲解原理,我们要实现这个IM聊天的通信功能,本文只考虑安全性问题。

那么我们的这个IM聊天功能,安全性上必需要达到:

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

好,带着这个问题,我来继续往下了解基本的通信安全知识。

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

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

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

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

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

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

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

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

5、如何确定对称加密算法

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

当然是通过协商:

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

6、如何对协商过程进行加密

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

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

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

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

7、协商什么加密算法

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

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

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

8、如何得到公钥?

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

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

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

方案1:服务器端将公钥发送给每一个用户端;

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

我们选择方案1,由于方案2又多了一次请求,还要另外解决公钥的放置问题。

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

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

我画了张图方便了解:

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

10、用第三方机构的公钥处理鸡生蛋蛋生鸡问题

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

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

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

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

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

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

假如能解密,就说明这个公钥没有被中间人调包。由于假如中间人用自己的私钥加密后的东西传给用户端,用户端是无法用第三方的公钥进行解密的。

原理图如下:

话到此,我以为处理问题了。但是现实中HTTPS,还有一个数字签名的概念,我没法了解它的设计理由。

原来,我漏掉了一个场景:

第三方机构不可能只给你一家公司制作证书,它也可能会给中间人这样有坏心思的公司发放证书。这样的,中间人就有机会对你的证书进行调包,用户端在这种情况下是无法分辨出是接收的是你的证书,还是中间人的。由于不管中间人,还是你的证书,都能用第三方机构的公钥进行解密。

像下面这样。。。

第三方机构向多家公司颁发证书的情况:?

用户端能解密同一家第三机构颁发的所有证书:?

最终导致其它持有同一家第三方机构证书的中间人可以进行调包:

11、数字签名,处理同一机构颁发的不同证书被篡改问题

要处理这个问题,我们首先要想清楚一个问题,辨别同一机构下不同证书的这个职责,我们应该放在哪?

只能放到用户端了。意思是,用户端在拿到证书后,自己就有能力分辨证书能否被篡改了。如何才能有这个能力呢?

我们从现实中找灵感。比方你是HR,你手上拿到候选人的学历证书,证书上写了持证人,颁发机构,颁发时间等等,同时证书上,还写有一个最重要的:证书编号!我们怎样鉴别这张证书是的真伪呢?只需拿着这个证书编号上相关机构去查,假如证书上的持证人与现实的这个候选人一致,同时证书编号也能对应上,那么就说明这个证书是真实的。

我们的用户端能不能采使用这个机制呢?像这样:?

可是,这个“第三方机构”究竟是在哪呢?是一个远端服务?不可能吧?假如是个远端服务,整个交互都会慢了。所以,这个第三方机构的验证功能只能放在用户端的本地了。

12、用户端本地怎样验证证书呢?

用户端本地怎样验证证书呢?答案是证书本身就已经告诉用户端怎样验证证书的真伪。

也就是证书上写着如何根据证书的内容生成证书编号。用户端拿到证书后根据证书上的方法自己生成一个证书编号,假如生成的证书编号与证书上的证书编号相同,那么说明这个证书是真实的。

同时,为避免证书编号本身又被调包,所以用第三方的私钥进行加密。

这地方有些笼统,我们来个图帮助了解:

证书的制作如上图所示。证书中的“编号生成方法MD5”就是告诉用户端:你用MD5对证书的内容求值即可以得到一个证书编号。

当用户端拿到证书后,开始对证书中的内容进行验证,假如用户端计算出来的证书编号与证书中的证书编号相同,则验证通过:

但是第三方机构的公钥怎样跑到了用户端的机器中呢?世界上这么多机器。

其实呢,现实中,浏览器和操作系统都会维护一个权威的第三方机构列表(包括它们的公钥)。由于用户端接收到的证书中会写有颁发机构,用户端就根据这个颁发机构的值在本地找相应的公钥。

题外话:

假如浏览器和操作系统这道防线被破了,就没办法。想想当年自己装过的非常规XP系统,都害怕。

说到这里,想必大家已经知道上文所说的,证书就是HTTPS中数字证书,证书编号就是数字签名,而第三方机构就是指数字证书签发机构(CA)。

13、CA如何颁发数字证书给服务器端的?

当我听到这个问题时,我误以为,我们的SERVER需要发网络请求到CA部门的服务器来拿这个证书。?? 究竟是我了解能力问题,还是。。

其实,问题应该是CA如何颁发给我们的网站管理员,而我们的管理员又如何将这个数字证书放到我们的服务器上。

我们如何向CA申请呢?每个CA机构都大同小异,我在网上找了一个:?

拿到证书后,我们即可以将证书配置到自己的服务器上了。那么如何配置?这是具体细节了,留给大家google了。

14、也许我们需要整理一下思路

我们通过推算的方式尝试复原HTTPS的设计过程。这样,我们也就明白了为什么HTTPS比HTTP多那么屡次的交互,为什么HTTPS的性能会差,以及找到HTTPS的性能优化点。

而上面一大堆工作都是为了让用户端与服务器端安全地协商出一个对称加密算法。这就是HTTPS中的SSL/TLS协议主要干的活。剩下的就是通信时双方用这个对称加密算法进行加密解密。

以下是一张HTTPS协议的真实交互图(从网上copy的,忘了从哪了,假如侵权麻烦告知):

15、能不能使用一句话总结HTTPS?

答案是不能,由于HTTPS本身实在太复杂。

但是我还是尝试用一段话来总结HTTPS:

HTTPS要使用户端与服务器端的通信过程得到安全保证,必需用的对称加密算法,但是协商对称加密算法的过程,需要用非对称加密算法来保证安全,然而直接用非对称加密的过程本身也不安全,会有中间人篡改公钥的可能性,所以用户端与服务器不直接用公钥,而是用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法,就此双方用该算法进行加密解密。从而处理了用户端与服务器端之间的通信安全问题。

好长的一段话。

16、后记

以上是个人为了解HTTPS而编造出来的自圆其说的看法。顶多只能算是HTTPS的科普文章。如有错误,请指出,万分感谢。

那么,我为什么会觉得以这种方式了解HTTPS会更容易呢?我个人给出的答案是:当你自己为一家人做一次菜时,你就会了解妈妈天天做菜的不易了。

17、参考资料

《HTTPS为什么安全 &分析 HTTPS 连接建立全过程》

《数字证书的基础知识》

《了解 HTTPS》

《HTTPS 是如何保证安全的?》

《图解SSL/TLS协议》

《The First Few Milliseconds of an HTTPS Connection》

《SSL/TLS原理详解》

附录:更多通信安全方面的文章

《传输层安全协议SSL/TLS的Java平台实现简介和Demo演示》

《理论联络实际:一套典型的IM通信协议设计详解(含安全层设计)》

《微信新一代通信安全处理方案:基于TLS1.3的MMTLS详解》

《来自阿里OpenIM:打造安全可靠即时通讯服务的技术实践分享》

《简述实时音视频聊天中端到端加密(E2EE)的工作原理》

《手机端安全通信的利器——端到端加密(E2EE)技术详解》

《Web端即时通讯安全:跨站点WebSocket劫持漏洞详解(含示例代码)》

《浅显易懂:一篇掌握即时通讯的消息传输安全原理》

《IM开发基础知识补课(四):正确了解HTTP短连接中的Cookie、Session和Token》

《快速读懂量子通信、量子加密技术》

《即时通讯安全篇(七):假如这样来了解HTTPS原理,一篇就够了》

>>?更多同类文章 ……

(本文同步发布于:http://www.52im.net/thread-1890-1-1.html)

  • 全部评论(0)
最新发布的资讯信息
【系统环境|服务器应用】用python写一个简单的词法分析器(2018-12-17 22:49)
【系统环境|服务器应用】Requirejs 和 AngularJS 中依赖注入(2018-12-17 22:49)
【系统环境|服务器应用】Excel 数据验证常用以及自己设置用法(2018-12-17 22:48)
【系统环境|服务器应用】WordPress 站点数据手动备份(2018-12-17 22:48)
【系统环境|服务器应用】20 个常用的 Excel 快捷键,瞬间提升工作效率(2018-12-17 22:48)
【系统环境|服务器应用】Java这些多线程基础知识你会吗?(2018-12-17 22:48)
【系统环境|服务器应用】vue中$refs的用法及作用详解(2018-12-17 22:47)
【系统环境|服务器应用】【轻知识】跑grpc的一个demo——Building APIs with GRPC, PHP, and Golang(2018-12-17 22:47)
【系统环境|服务器应用】Golang学习笔记之包管理工具(govendor)(2018-12-17 22:47)
【系统环境|服务器应用】阿里云sn1ne实例和sn2ne实例比较(2018-12-17 22:47)
手机二维码手机访问领取大礼包
返回顶部