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