若是这样来理解HTTPS，一篇就够了！
一、前言
可能有初学者会问，即时通信应用的通讯安全，不就是对Socket长链接进行SSL/TLS加密这些知识吗，干嘛要理解HTTPS协议呢。php
这实际上是个误解：当今主流的移动端IM数据通讯，总结下来无外乎就是长链接+短链接的方式，长链接就是众所周之的TCP、UDP、WebSocket（WebSocket的本质仍是TCP），而短链接就是HTTP/HTTPS了。即时通信IM应用中，短链接的安全跟长链接相比，一样很重要。市面上的主流短链接通讯方式，都已逐步从HTTP过渡到HTTPS了（iOS上的应用就更完全了，苹果直接强制要求使用HTTPS协议，不然不容许上架APP Store，详见《苹果即将强制实施 ATS，你的APP准备好切换到HTTPS了吗？》。不过，鉴于多方面缘由，苹果实际上推迟了ATS的强制执行，有兴趣能够到苹果官方了解）。html
题外话：关于短链接、长链接的定义，微信是一个特例，微信在网络通讯这一层作的比较完全和极端，几乎再造了一套针对移动端IM的网络层框架（详见：《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》），因此针对微信来讲短链接可能并不能就是HTTP/HTTPS了。git
总之，不管是即时通信IM仍是其它应用，在移动网络日益发达的今天，安全显的尤其重要，HTTPS已经愈来愈普及，尽快拥抱它才是符合技术潮流的。github
本文将尝试用通俗易懂的语言，一步步还原HTTPS的设计过程，以便您能轻松理解为何HTTPS最终会是这副模样。但鉴于HTTPS的复杂性，本文的文字主要是为了方便您的理解，而并不表明彻底听从HTTPS的真实设计过程。在阅读本文时，你能够尝试放下已有的对HTTPS的理解，这样更利于您“理解”这个过程和技术原理。算法
学习交流：编程
- 即时通信开发交流3群：185926912[推荐]segmentfault
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》浏览器
（本文同步发布于：http://www.52im.net/thread-1890-1-1.html）安全
二、关于做者
翟志军，我的博客地址：https://showme.codes/，Github：https://github.com/zacker330。感谢做者的原创分享。性能优化
三、相关文章
要理解HTTPS，须对HTTP协议有所了解，如下文章多是您须要的：
《从HTTP/0.9到HTTP/2：一文读懂HTTP协议的历史演变和设计思路》
《脑残式网络编程入门(三)：HTTP协议必知必会的一些知识》
本文是IM通信安全知识系列文章中的第7篇，此系列总目录以下：
《即时通信安全篇（一）：正确地理解和使用Android端加密算法》
《即时通信安全篇（四）：实例分析Android中密钥硬编码的风险》
四、一个引子
咱们先不了聊HTTP/HTTPS，咱们先从一个IM聊天软件提及。
假设咱们想要实现A能发一个hello消息给B：
由于只是为了方便讲解原理，咱们要实现这个IM聊天的通讯功能，本文只考虑安全性问题。
那么咱们的这个IM聊天功能，安全性上必需要达到：
A发给B的hello消息包，即便被中间人拦截到了，也没法得知消息的内容。
好，带着这个问题，我来继续往下理解基本的通讯安全知识。
好，问题域已经定义好了（现实中固然不止这一种定义）。对于解决方案，很容易就想到了对消息进行加密。
题外话，可是只有这一种方法吗？我看未必，说不定在未来会出现一种物质打破当前世界的通讯假设，实现真正意义上的保密。
对于A与B这样的简单通讯模型，咱们很容易作出选择： 对称加密算法
这就是对称加密算法，其中图中的密钥S同时扮演加密和解密的角色。具体细节不是本文范畴。
如上图所示，只要这个密钥S不公开给第三者，同时密钥S足够安全，咱们就解决了咱们一开始所定问题域了。由于世界上有且只有A与B知道如何加密和解密他们之间的消息。
可是，在WWW环境下，咱们的Web服务器的通讯模型没有这么简单：
若是服务器端对全部的客户端通讯都使用一样的对称加密算法，无异于没有加密。那怎么办呢？即能使用对称加密算法，又不公开密钥？请读者思考21秒钟。^_^
答案是：Web服务器与每一个客户端使用不一样的对称加密算法：
五、如何肯定对称加密算法
慢着，另外一个问题来了，咱们的服务器端怎么告诉客户端该使用哪一种对称加密算法？
固然是经过协商：
可是，你协商的过程是没有加密的，仍是会被中间人拦截。那咱们再对这个协商过程进行对称加密就行了，那你对协商过程加密的加密仍是没有加密，怎么办？再加密不就行了……好吧，进行鸡生蛋蛋生鸡的问题了。
六、如何对协商过程进行加密
新问题来了，如何对协商过程进行加密？密码学领域中，有一种称为“非对称加密”的加密算法，特色是私钥加密后的密文，只要是公钥，均可以解密，可是公钥加密后的密文，只有私钥能够解密。私钥只有一我的有，而公钥能够发给全部的人。
虽然服务器端向A、B……的方向仍是不安全的，可是至少A、B向服务器端方向是安全的。
好了，如何协商加密算法的问题，咱们解决了：使用非对称加密算法进行对称加密算法协商过程。
这下，你明白为何HTTPS同时须要对称加密算法和非对称加密算法了吧？
七、协商什么加密算法
要达到Web服务器针对每一个客户端使用不一样的对称加密算法，同时，咱们也不能让第三者知道这个对称加密算法是什么，怎么办？
使用随机数，就是使用随机数来生成对称加密算法。这样就能够作到服务器和客户端每次交互都是新的加密算法、只有在交互的那一该才肯定加密算法。
这下，你明白为何HTTPS协议握手阶段会有这么多的随机数了吧。
八、如何获得公钥？
细心的人可能已经注意到了若是使用非对称加密算法，咱们的客户端A，B须要一开始就持有公钥，要不无法开展加密行为啊。
这下，咱们又遇到新问题了，如何让A、B客户端安全地获得公钥？
我能想到的方案只有这些：
方案1：服务器端将公钥发送给每个客户端；
方案2：服务器端将公钥放到一个远程服务器，客户端能够请求获得。
咱们选择方案1，由于方案2又多了一次请求，还要另外处理公钥的放置问题。
九、公钥被调包了怎么办？又是一个鸡生蛋蛋生鸡问题？
可是方案1有个问题：若是服务器端发送公钥给客户端时，被中间人调包了，怎么办？
我画了张图方便理解：
显然，让每一个客户端的每一个浏览器默认保存全部网站的公钥是不现实的。
十、使用第三方机构的公钥解决鸡生蛋蛋生鸡问题
公钥被调包的问题出现，是由于咱们的客户端没法分辨返回公钥的人究竟是中间人，仍是真的服务器。这其实就是密码学中提的身份验证问题。
若是让你来解决，你怎么解决？若是你了解过HTTPS，会知道使用数字证书来解决。可是你想过证书的本质是什么么？请放下你对HTTPS已有的知识，本身尝试找到解决方案。
我是这样解决的。既然服务器须要将公钥传给客户端，这个过程自己是不安全，那么咱们为何不对这个过程自己再加密一次？但是，你是使用对称加密，仍是非对称加密？这下好了，我感受又进了鸡生蛋蛋生鸡问题了。
问题的难点是若是咱们选择直接将公钥传递给客户端的方案，咱们始终没法解决公钥传递被中间人调包的问题。
因此，咱们不能直接将服务器的公钥传递给客户端，而是第三方机构使用它的私钥对咱们的公钥进行加密后，再传给客户端。客户端再使用第三方机构的公钥进行解密。
下图就是咱们设计的初版“数字证书”，证书中只有服务器交给第三方机构的公钥，并且这个公钥被第三方机构的私钥加密了：
若是能解密，就说明这个公钥没有被中间人调包。由于若是中间人使用本身的私钥加密后的东西传给客户端，客户端是没法使用第三方的公钥进行解密的。
原理图以下：
话到此，我觉得解决问题了。可是现实中HTTPS，还有一个数字签名的概念，我无法理解它的设计理由。
原来，我漏掉了一个场景：
第三方机构不可能只给你一家公司制做证书，它也可能会给中间人这样有坏心思的公司发放证书。这样的，中间人就有机会对你的证书进行调包，客户端在这种状况下是没法分辨出是接收的是你的证书，仍是中间人的。由于不论中间人，仍是你的证书，都能使用第三方机构的公钥进行解密。
像下面这样。。。
第三方机构向多家公司颁发证书的状况：
客户端能解密同一家第三机构颁发的全部证书：
最终致使其它持有同一家第三方机构证书的中间人能够进行调包：
十一、数字签名，解决同一机构颁发的不一样证书被篡改问题
要解决这个问题，咱们首先要想清楚一个问题，辨别同一机构下不一样证书的这个职责，咱们应该放在哪？
只能放到客户端了。意思是，客户端在拿到证书后，本身就有能力分辨证书是否被篡改了。如何才能有这个能力呢？
咱们从现实中找灵感。好比你是HR，你手上拿到候选人的学历证书，证书上写了持证人，颁发机构，颁发时间等等，同时证书上，还写有一个最重要的：证书编号！咱们怎么鉴别这张证书是的真伪呢？只要拿着这个证书编号上相关机构去查，若是证书上的持证人与现实的这个候选人一致，同时证书编号也能对应上，那么就说明这个证书是真实的。
咱们的客户端能不能采用这个机制呢？像这样：
但是，这个“第三方机构”究竟是在哪呢？是一个远端服务？不可能吧？若是是个远端服务，整个交互都会慢了。因此，这个第三方机构的验证功能只能放在客户端的本地了。
十二、客户端本地怎么验证证书呢？
客户端本地怎么验证证书呢？答案是证书自己就已经告诉客户端怎么验证证书的真伪。
也就是证书上写着如何根据证书的内容生成证书编号。客户端拿到证书后根据证书上的方法本身生成一个证书编号，若是生成的证书编号与证书上的证书编号相同，那么说明这个证书是真实的。
同时，为避免证书编号自己又被调包，因此使用第三方的私钥进行加密。
这地方有些抽象，咱们来个图帮助理解：
证书的制做如上图所示。证书中的“编号生成方法MD5”就是告诉客户端：你使用MD5对证书的内容求值就能够获得一个证书编号。
当客户端拿到证书后，开始对证书中的内容进行验证，若是客户端计算出来的证书编号与证书中的证书编号相同，则验证经过：
可是第三方机构的公钥怎么跑到了客户端的机器中呢？世界上这么多机器。
其实呢，现实中，浏览器和操做系统都会维护一个权威的第三方机构列表（包括它们的公钥）。由于客户端接收到的证书中会写有颁发机构，客户端就根据这个颁发机构的值在本地找相应的公钥。
题外话：
若是浏览器和操做系统这道防线被破了，就没办法。想一想当年本身装过的很是规XP系统，都惧怕。
说到这里，想必你们已经知道上文所说的，证书就是HTTPS中数字证书，证书编号就是数字签名，而第三方机构就是指数字证书签发机构（CA）。
1三、CA如何颁发数字证书给服务器端的？
当我听到这个问题时，我误觉得，咱们的SERVER须要发网络请求到CA部门的服务器来拿这个证书。 究竟是我理解能力问题，仍是。。
其实，问题应该是CA如何颁发给咱们的网站管理员，而咱们的管理员又如何将这个数字证书放到咱们的服务器上。
咱们如何向CA申请呢？每一个CA机构都大同小异，我在网上找了一个：
拿到证书后，咱们就能够将证书配置到本身的服务器上了。那么如何配置？这是具体细节了，留给你们google了。
1四、也许咱们须要整理一下思路
咱们经过推算的方式尝试还原HTTPS的设计过程。这样，咱们也就明白了为何HTTPS比HTTP多那么屡次的交互，为何HTTPS的性能会差，以及找到HTTPS的性能优化点。
而上面一大堆工做都是为了让客户端与服务器端安全地协商出一个对称加密算法。这就是HTTPS中的SSL/TLS协议主要干的活。剩下的就是通讯时双方使用这个对称加密算法进行加密解密。
如下是一张HTTPS协议的真实交互图（从网上copy的，忘了从哪了，若是侵权麻烦告知）：
1五、能不能用一句话总结HTTPS？
答案是不能，由于HTTPS自己实在太复杂。
可是我仍是尝试使用一段话来总结HTTPS:
HTTPS要使客户端与服务器端的通讯过程获得安全保证，必须使用的对称加密算法，可是协商对称加密算法的过程，须要使用非对称加密算法来保证安全，然而直接使用非对称加密的过程自己也不安全，会有中间人篡改公钥的可能性，因此客户端与服务器不直接使用公钥，而是使用数字证书签发机构颁发的证书来保证非对称加密过程自己的安全。这样经过这些机制协商出一个对称加密算法，就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通讯安全问题。
好长的一段话。
1六、后记
以上是我的为理解HTTPS而编造出来的自圆其说的见解。顶多只能算是HTTPS的科普文章。若有错误，请指出，万分感谢。
那么，我为何会以为以这种方式理解HTTPS会更容易呢？我我的给出的答案是：当你本身为一家人作一次菜时，你就会理解妈妈每天作菜的不易了。
1七、参考资料
《理解 HTTPS》
附录：更多通讯安全方面的文章
《传输层安全协议SSL/TLS的Java平台实现简介和Demo演示》
《理论联系实际：一套典型的IM通讯协议设计详解（含安全层设计）》
《微信新一代通讯安全解决方案：基于TLS1.3的MMTLS详解》
《来自阿里OpenIM：打造安全可靠即时通信服务的技术实践分享》
《Web端即时通信安全：跨站点WebSocket劫持漏洞详解(含示例代码)》
《IM开发基础知识补课(四)：正确理解HTTP短链接中的Cookie、Session和Token》
《即时通信安全篇（七）：若是这样来理解HTTPS原理，一篇就够了》
>> 更多同类文章 ……
（本文同步发布于：http://www.52im.net/thread-1890-1-1.html）
- 1. HTTPS协议，看这一篇就够了
- 2. [译] 理解CORS这一篇就够了
- 3. 了解 MongoDB 看这一篇就够了
- 4. 了解爬虫，这一篇就够了！
- 5. 了解HandlerThread这一篇就够了
- 6. nginx 这一篇就够了
- 7. Ajax这一篇就够了????
- 8. 解密Cookie，这一篇就够了
- 9. 图解Word2vec，读这一篇就够了
- 10. 看这一篇就够了！-Ajax详解
- 更多相关文章...
- • CAP理论是什么？ - NoSQL教程
- • 物理地址（MAC地址）是什么？ - TCP/IP教程
- • 三篇文章了解 TiDB 技术内幕——说存储
- • 三篇文章了解 TiDB 技术内幕 —— 说计算
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. HTTPS协议，看这一篇就够了
- 2. [译] 理解CORS这一篇就够了
- 3. 了解 MongoDB 看这一篇就够了
- 4. 了解爬虫，这一篇就够了！
- 5. 了解HandlerThread这一篇就够了
- 6. nginx 这一篇就够了
- 7. Ajax这一篇就够了????
- 8. 解密Cookie，这一篇就够了
- 9. 图解Word2vec，读这一篇就够了
- 10. 看这一篇就够了！-Ajax详解