前天寫了一篇關於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 私鑰加密長文本時的時間問題，另一方面也會導致客戶端校驗時拿著兩個大證書的全部資訊校驗，很浪費。

再例如我們下載檔案時，會有個檔案的雜湊值做校驗，看下載過程中有沒有變化。

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