叮咚 | HTTPS 的分支和主干

发表于 3年以前 | 总阅读数：363 次

昨天写了一个关于 HTTPS 的文章，[《破玩意 | 用 HTTPS 传纸条》] 。

发现还是有不少人对 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 私钥加密长文本时的时间问题，另一方面也会导致客户端校验时拿着两个大证书的全部信息校验，很浪费。