不少同學對 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 裏是分支不是主幹知識。
👇🏻 點選下方閱讀原文，獲取魚皮往期編程幹貨。
往期推薦
