為什麼你理解不了HTTPS 的原理


網路網路管理
CA 機構那邊也有一套公私鑰。服務端把自己的公鑰給CA,讓CA 用CA 的私鑰加密,然後回傳加密結果。然後這個加密結果,可以用CA 的公鑰解,誰都可以解開。

前天寫了一篇關於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 裡是分支不是主幹知識。