前天寫了一個關于 HTTPS 的文章，你管這破玩意叫 HTTPS。

看評論區(qū)和私信，發(fā)現還是有不少人對 HTTPS 不理解，我大概分析了一下，之所以覺得 HTTPS 這個東西比較難理解，往往是沒有分清主干和分支導致的。

HTTPS 的主干非常簡單，其實就三層而已。

第一層

第一層，是主干的主干，就一句話，加密通信就是雙方都持有一個對稱加密的秘鑰，然后就可以安全通信了，就這么簡單。

再說一遍，雙方都持有一個對稱加密的秘鑰，安全通信，結束了。

這個秘鑰是啥？

1. 可以是客戶端自己拍腦門想一個，然后傳給服務端。

2. 也可以是服務端自己拍腦門想一個，然后傳給客戶端。

3. 或者雙方都想一串數字，然后組合起來。

這些都不重要，無論玩出多少花樣，最終的目標都是，讓雙方協(xié)商出一個相同的秘鑰，然后用它對稱加密通信，就安全了。

我想如果從這個簡單的出發(fā)點講 HTTPS，沒人會聽不懂。

但現在大量的文章邏輯都是，先拋出一堆概念讓你消化。

對稱加密、非對稱加密、公鑰、私鑰、加密、簽名、摘要、證書、CA 機構、中間人等等。

然后你都不知道 HTTPS 要干嘛，就先被這些名詞搞蒙圈了。

再說最后一遍，HTTPS 要做的事，就是讓雙方協(xié)商出一個相同的秘鑰，然后對稱加密，安全通信就結束了。

先把這個事記住再往下推，因為其他所有的騷操作，都是為了完成這一個簡簡單單的小目標而已。

那協(xié)商出一個相同的秘鑰這個過程有啥問題呢？

問題就是，無論這個最初的秘鑰是由客戶端傳給服務端，還是服務端傳給客戶端，都是明文傳輸，中間人都可以知道。

那就讓這個過程變成密文就好了唄，而且還得是中間人解不開的密文。

這就到了第二層。

第二層

這才涉及到非對稱加密這個事。

非對稱加密有兩種方式，公鑰加密私鑰解密，私鑰加密公鑰解密。

此時我們需要的是第一種。

服務端把它的公鑰明晃晃地扔給我，然后我用公鑰把我要傳給服務端的對稱加密的秘鑰，加密。

此時傳遞的就是加密的數據了，而且只能服務端用私鑰才能解開，中間人無法得知。

OK，這一步就是說，只要服務端成功把它的公鑰扔給我，后面的事就順理成章了。

但是這一步公鑰也是明文傳輸，但是相比一開始已經有了進步。

因為秘鑰傳輸既怕別人看到，也怕別人篡改。

但此時的公鑰已經不怕別人看到了，看到就看到唄，你知道公鑰，也解不開客戶端用公鑰加密的秘鑰。

但是，仍然怕篡改。

中間人通過篡改，最終可以獲得你們的秘鑰，這個過程很簡單，就放上篇文章的圖了。

圖片

永遠記住，你們的最終目標，就是協(xié)商出一個秘鑰，來對稱加密通信。

而中間人的目標，也是要想辦法知道你們的秘鑰，其他的都不重要。

永遠別忘了最初的目標。

怎么防止這個公鑰被篡改，就是第三層了。

第三層

服務端給我的公鑰，怎么防止別人篡改呢？

我可以先自己生成一對公私鑰，然后把公鑰給服務端，服務端用我的公鑰給它的公鑰加密，這就沒法篡改了，甚至中間人連公鑰是啥都不知道了，完美。

可是我給服務端公鑰的過程又變成明文了，又容易被篡改，那怎么辦呢？

那可以服務端給我公鑰，然后我用這個公鑰加密我的公鑰傳給服務端。

那服務端給我公鑰又是明文，又容易被篡改。

那可以...

這你發(fā)現了吧，套娃了，永遠有那么第一次的明文內容，會被中間人篡改。

怎么消除這個第一次明文的尷尬呢？

CA 機構。

CA 機構那邊也有一套公私鑰。

服務端把自己的公鑰給 CA，讓 CA 用 CA 的私鑰加密，然后返回加密結果。

然后這個加密結果，可以用 CA 的公鑰解，誰都可以解開。

但是，如果要篡改結果，必須再次用 CA 的私鑰加密，可是這個做不到，只要 CA 不是壞蛋即可。

這就做到了第一次的明文傳輸的公鑰，只能被看，無法被篡改。

于是中間人就只能眼睜睜看著一個自己知道的公鑰，從服務端傳給客戶端。

然后客戶端用這個公鑰，給之后對稱加密的秘鑰加密，傳給服務端，中間人由于不知道服務端私鑰，解不開。

于是，客戶端和服務端，有了一個中間人不知道的，解不開的對稱秘鑰。

之后就 OK 了。

總結

總結起來就是。

第一層：雙方的通信就是簡單的對稱加密方式通信。

第二層：https 僅僅是解決對稱加密的密鑰怎么安全傳給對方，那就是用非對稱加密方式（公鑰加密私鑰解密：加密）。

第三層：那非對稱加密的公鑰傳遞如何防篡改，那就是 CA 機構的非對稱加密（私鑰加密公鑰解密：簽名）。

其他的我覺得都不是主干，都是旁路細節(jié)。

再看之前那些名詞，

對稱加密、非對稱加密、秘鑰，公鑰、私鑰、加密、簽名、摘要、證書、CA 機構、中間人。

怎么全串起來呢？很簡單。

對稱加密是一種算法，只有一個秘鑰。

非對稱加密也是一種算法，有兩個秘鑰，自己保密的叫私鑰，對外公開的叫公鑰。

公鑰加密，私鑰解密，這個叫加密，客戶端用服務端公鑰加密自己的秘鑰傳過去，就是這個目的。

私鑰加密，公鑰解密，這個叫簽名，CA 機構用私鑰加密服務端的公鑰信息生成簽名，就是這個過程，其目的是為了防止篡改。

上一篇文章也說到了，這就好像一把神奇的雙鑰匙鎖一樣。

圖片

還有一個詞是哈希摘要，這也是個算法，特點是只能正著推，不能反著推，而且無論原文多大，哈希摘要后都一樣大。這個主要用于校驗，我覺得是個分支，因為沒有它也行。

比如 CA 實際上，不是簡簡單單對服務端的公鑰進行加密，而是對證書的哈希摘要進行加密（其實證書就是服務端公鑰，加上一些其他信息，比如服務端域名，頒發(fā)機構等等）

圖片

你看這一步，沒有那個哈希摘要是不是也沒事，只不過，一方面會導致 CA 私鑰加密長文本時的時間問題，另一方面也會導致客戶端校驗時拿著兩個大證書的全部信息校驗，很浪費。

再比如我們下載文件時，會有個文件的哈希值做校驗，看下載過程中有沒有變化。

其實這也是方便校驗罷了，所以我說它在 HTTPS 里是分支不是主干知識。