看评论区和私信，发现还是有不少人对 HTTPS 不理解，我大概分析了一下，之所以觉得 HTTPS 这个东西比较难理解，往往是没有分清主干和分支导致的。
HTTPS 的主干非常简单，其实就三层而已。
第一层
第一层，是主干的主干，就一句话，加密通信就是双方都持有一个对称加密的秘钥，然后就可以安全通信了，就这么简单。
再说一遍，双方都持有一个对称加密的秘钥，安全通信，结束了。
这个秘钥是啥？
1. 可以是客户端自己拍脑门想一个，然后传给服务端。
2. 也可以是服务端自己拍脑门想一个，然后传给客户端。
3. 或者双方都想一串数字，然后组合起来。
这些都不重要，无论玩出多少花样，最终的目标都是，让双方协商出一个相同的秘钥，然后用它对称加密通信，就安全了。
我想如果从这个简单的出发点讲 HTTPS，没人会听不懂。
但现在大量的文章逻辑都是，先抛出一堆概念让你消化。
对称加密、非对称加密、公钥、私钥、加密、签名、摘要、证书、CA 机构、中间人等等。
然后你都不知道 HTTPS 要干嘛，就先被这些名词搞蒙圈了。
再说最后一遍，HTTPS 要做的事，就是让双方协商出一个相同的秘钥，然后对称加密，安全通信就结束了。
先把这个事记住再往下推，因为其他所有的骚操作，都是为了完成这一个简简单单的小目标而已。
那协商出一个相同的秘钥这个过程有啥问题呢？
问题就是，无论这个最初的秘钥是由客户端传给服务端，还是服务端传给客户端，都是明文传输，中间人都可以知道。
那就让这个过程变成密文就好了呗，而且还得是中间人解不开的密文。
这就到了第二层。
第二层
这才涉及到非对称加密这个事。
非对称加密有两种方式，公钥加密私钥解密，私钥加密公钥解密。
此时我们需要的是第一种。
服务端把它的公钥明晃晃地扔给我，然后我用公钥把我要传给服务端的对称加密的秘钥，加密。
此时传递的就是加密的数据了，而且只能服务端用私钥才能解开，中间人无法得知。
OK，这一步就是说，只要服务端成功把它的公钥扔给我，后面的事就顺理成章了。
但是这一步公钥也是明文传输，但是相比一开始已经有了进步。
因为秘钥传输既怕别人看到，也怕别人篡改。
但此时的公钥已经不怕别人看到了，看到就看到呗，你知道公钥，也解不开客户端用公钥加密的秘钥。
但是，仍然怕篡改。
中间人通过篡改，最终可以获得你们的秘钥，这个过程很简单，就放上篇文章的图了。
图片
永远记住，你们的最终目标，就是协商出一个秘钥，来对称加密通信。
而中间人的目标，也是要想办法知道你们的秘钥，其他的都不重要。
永远别忘了最初的目标。
怎么防止这个公钥被篡改，就是第三层了。
第三层
服务端给我的公钥，怎么防止别人篡改呢？
我可以先自己生成一对公私钥，然后把公钥给服务端，服务端用我的公钥给它的公钥加密，这就没法篡改了，甚至中间人连公钥是啥都不知道了，完美。
可是我给服务端公钥的过程又变成明文了，又容易被篡改，那怎么办呢？
那可以服务端给我公钥，然后我用这个公钥加密我的公钥传给服务端。
那服务端给我公钥又是明文，又容易被篡改。
那可以...
这你发现了吧，套娃了，永远有那么第一次的明文内容，会被中间人篡改。
怎么消除这个第一次明文的尴尬呢？
CA 机构。
CA 机构那边也有一套公私钥。
服务端把自己的公钥给 CA，让 CA 用 CA 的私钥加密，然后返回加密结果。
然后这个加密结果，可以用 CA 的公钥解，谁都可以解开。
但是，如果要篡改结果，必须再次用 CA 的私钥加密，可是这个做不到，只要 CA 不是坏蛋即可。
这就做到了第一次的明文传输的公钥，只能被看，无法被篡改。
于是中间人就只能眼睁睁看着一个自己知道的公钥，从服务端传给客户端。
然后客户端用这个公钥，给之后对称加密的秘钥加密，传给服务端，中间人由于不知道服务端私钥，解不开。
于是，客户端和服务端，有了一个中间人不知道的，解不开的对称秘钥。
之后就 OK 了。
总结
总结起来就是。
第一层：双方的通信就是简单的对称加密方式通信。
第二层：https 仅仅是解决对称加密的密钥怎么安全传给对方，那就是用非对称加密方式（公钥加密私钥解密：加密）。
第三层：那非对称加密的公钥传递如何防篡改，那就是 CA 机构的非对称加密（私钥加密公钥解密：签名）。
其他的我觉得都不是主干，都是旁路细节。
再看之前那些名词，
对称加密、非对称加密、秘钥，公钥、私钥、加密、签名、摘要、证书、CA 机构、中间人。
怎么全串起来呢？很简单。
对称加密是一种算法，只有一个秘钥。
非对称加密也是一种算法，有两个秘钥，自己保密的叫私钥，对外公开的叫公钥。
公钥加密，私钥解密，这个叫加密，客户端用服务端公钥加密自己的秘钥传过去，就是这个目的。
私钥加密，公钥解密，这个叫签名，CA 机构用私钥加密服务端的公钥信息生成签名，就是这个过程，其目的是为了防止篡改。
上一篇文章也说到了，这就好像一把神奇的双钥匙锁一样。
图片
还有一个词是哈希摘要，这也是个算法，特点是只能正着推，不能反着推，而且无论原文多大，哈希摘要后都一样大。这个主要用于校验，我觉得是个分支，因为没有它也行。
比如 CA 实际上，不是简简单单对服务端的公钥进行加密，而是对证书的哈希摘要进行加密（其实证书就是服务端公钥，加上一些其他信息，比如服务端域名，颁发机构等等）
图片
你看这一步，没有那个哈希摘要是不是也没事，只不过，一方面会导致 CA 私钥加密长文本时的时间问题，另一方面也会导致客户端校验时拿着两个大证书的全部信息校验，很浪费。
再比如我们下载文件时，会有个文件的哈希值做校验，看下载过程中有没有变化。
其实这也是方便校验罢了，所以我说它在 HTTPS 里是分支不是主干知识。
