以图文的方式解锁 HTTPS原理，10分钟复原HTTPS真像！架构师必读

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

我们先不了聊HTTP，HTTPS，我们先从一个聊天软件说起，我们要实现A可以发一个hello消息给B：

假如我们要实现这个聊天软件，本文只考虑安全性问题，要实现：

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

如何做到真正的安全？

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

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

我个人的了解是：

A与B通信的内容，有且只有A和B有可以力看到通信的真正内容

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

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

对于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）。

CA如何颁发数字证书给服务器端的？

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

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

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

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

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

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

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

以下是一张HTTPS协议的真实交互图（从网上copy的，忘了从哪了，假如侵权麻烦告知）：

可以不可以使用一句话总结HTTPS？

答案是不可以，由于HTTPS本身实在太复杂。但是我还是尝试用一段话来总结HTTPS:

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

作者：翟志军