https原理通俗瞭解

標籤：方式   協助   img   另一個   客戶   可能性   產生   遠程服務   密碼學   

摘要：本文嘗試一步步還原HTTPS的設計過程，以理解為什麼HTTPS最終會是這副模樣。但是這並不代表HTTPS的真實設計過程。在閱讀本文時，你可以嘗試放下已有的對HTTPS的理解，這樣更利於“還原”過程。

我們先不了聊HTTP，HTTPS，我們先從一個聊天軟體說起，我們要實現A能發一個hello訊息給B：

如果我們要實現這個聊天軟體，本文只考慮安全性問題，要實現

A發給B的hello訊息包，即使被中間人攔截到了，也無法得知訊息的內容

如何做到真正的安全？

這個問題，很多人馬上就想到了各種密碼編譯演算法，什麼對稱式加密、非對稱式加密、DES、RSA、XX、劈裡啪啦~

而我想說，密碼編譯演算法只是解決方案，我們首先要做的是理解我們的問題域——什麼是安全？

我個人的理解是：

A與B通訊的內容，有且只有A和B有能力看到通訊的真正內容

好，問題域已經定義好了（現實中當然不止這一種定義）。對於解決方案，很容易就想到了對訊息進行加密。

題外話，但是只有這一種方法嗎？我看未必，說不定在將來會出現一種物質打破當前世界的通訊假設，實現真正意義上的保密。

對於A與B這樣的簡單通訊模型，我們很容易做出選擇：

這就是對稱式加密演算法，其中圖中的密鑰S同時扮演加密和解密的角色。具體細節不是本文範疇。

只要這個密鑰S不公開給第三者，同時密鑰S足夠安全，我們就解決了我們一開始所定問題域了。因為世界上有且只有A與B知道如何加密和解密他們之間的訊息。

但是，在WWW環境下，我們的Web伺服器的通訊模型沒有這麼簡單：

如果伺服器端對所有的用戶端通訊都使用同樣的對稱式加密演算法，無異於沒有加密。那怎麼辦呢？即能使用對稱式加密演算法，又不公開密鑰？請讀者思考21秒鐘。??

答案是：Web伺服器與每個用戶端使用不同的對稱式加密演算法：

如何確定對稱式加密演算法

慢著，另一個問題來了，我們的伺服器端怎麼告訴用戶端該使用哪種對稱式加密演算法？

當然是通過協商。

但是，你協商的過程是沒有加密的，還是會被中間人攔截。那我們再對這個協商過程進行對稱式加密就好了，那你對協商過程加密的加密還是沒有加密，怎麼辦？再加密不就好了……好吧，進行雞生蛋蛋生雞的問題了。

如何對協商過程進行加密

新問題來了，如何對協商過程進行加密？密碼學領域中，有一種稱為“非對稱式加密”的密碼編譯演算法，特點是私密金鑰加密後的密文，只要是公開金鑰，都可以解密，但是公開金鑰加密後的密文，只有私密金鑰可以解密。私密金鑰只有一個人有，而公開金鑰可以發給所有的人。

雖然伺服器端向A、B……的方向還是不安全的，但是至少A、B向伺服器端方向是安全的。

好了，如何協商密碼編譯演算法的問題，我們解決了：使用非對稱式加密演算法進行對稱式加密演算法協商過程。

這下，你明白為什麼HTTPS同時需要對稱式加密演算法和非對稱式加密演算法了吧？

協商什麼密碼編譯演算法

要達到Web伺服器針對每個用戶端使用不同的對稱式加密演算法，同時，我們也不能讓第三者知道這個對稱式加密演算法是什麼，怎麼辦？

使用隨機數，就是使用隨機數來產生對稱式加密演算法。這樣就可以做到伺服器和用戶端每次互動都是新的密碼編譯演算法、只有在互動的那一該才確定密碼編譯演算法。

這下，你明白為什麼HTTPS協議握手階段會有這麼多的隨機數了吧。

如何得到公開金鑰？

細心的人可能已經注意到了如果使用非對稱式加密演算法，我們的用戶端A，B需要一開始就持有公開金鑰，要不沒法開展加密行為啊。

這下，我們又遇到新問題了，如何讓A、B用戶端安全地得到公開金鑰？

我能想到的方案只有這些：

方案1. 伺服器端將公開金鑰發送給每一個用戶端

方案2. 伺服器端將公開金鑰放到一個遠程伺服器，用戶端可以請求得到

我們選擇方案1，因為方案2又多了一次請求，還要另外處理公開金鑰的放置問題。

公開金鑰被調包了怎麼辦？又是一個雞生蛋蛋生雞問題？

但是方案1有個問題：如果伺服器端發送公開金鑰給用戶端時，被中間人調包了，怎麼辦？

我畫了張圖方便理解：

顯然，讓每個用戶端的每個瀏覽器預設儲存所有網站的公開金鑰是不現實的。

使用第三方機構的公開金鑰解決雞生蛋蛋生雞問題

公開金鑰被調包的問題出現，是因為我們的用戶端無法分辨返回公開金鑰的人到底是中間人，還是真的伺服器。這其實就是密碼學中提的身分識別驗證問題。

如果讓你來解決，你怎麼解決？如果你瞭解過HTTPS，會知道使用數位憑證來解決。但是你想過認證的本質是什麼嗎？請放下你對HTTPS已有的知識，自己嘗試找到解決方案。

我是這樣解決的。既然伺服器需要將公開金鑰傳給用戶端，這個過程本身是不安全，那麼我們為什麼不對這個過程本身再加密一次？可是，你是使用對稱式加密，還是非對稱式加密？這下好了，我感覺又進了雞生蛋蛋生雞問題了。

問題的痛點是如果我們選擇直接將公開金鑰傳遞給用戶端的方案，我們始終無法解決公開金鑰傳遞被中間人調包的問題。

所以，我們不能直接將伺服器的公開金鑰傳遞給用戶端，而是第三方機構使用它的私密金鑰對我們的公開金鑰進行加密後，再傳給用戶端。用戶端再使用第三方機構的公開金鑰進行解密。

就是我們設計的第一版“數位憑證”，認證中只有伺服器交給第三方機構的公開金鑰，而且這個公開金鑰被第三方機構的私密金鑰加密了：

如果能解密，就說明這個公開金鑰沒有被中間人調包。因為如果中間人使用自己的私密金鑰加密後的東西傳給用戶端，用戶端是無法使用第三方的公開金鑰進行解密的。

話到此，我以為解決問題了。但是現實中HTTPS，還有一個數位簽章的概念，我沒法理解它的設計理由。

原來，我漏掉了一個情境：第三方機構不可能只給你一家公司製作認證，它也可能會給中間人這樣有壞心思的公司發放認證。這樣的，中間人就有機會對你的認證進行調包，用戶端在這種情況下是無法分辨出是接收的是你的認證，還是中間人的。因為不論中間人，還是你的認證，都能使用第三方機構的公開金鑰進行解密。像下面這樣：

第三方機構向多家公司頒發認證的情況：

用戶端能解密同一家第三機構頒發的所有認證：

最終導致其它持有同一家第三方機構認證的中間人可以進行調包：

數位簽章，解決同一機構頒發的不同認證被篡改問題

要解決這個問題，我們首先要想清楚一個問題，辨別同一機構下不同認證的這個職責，我們應該放在哪？

只能放到用戶端了。意思是，用戶端在拿到認證後，自己就有能力分辨認證是否被篡改了。如何才能有這個能力呢？

我們從現實中找靈感。比如你是HR，你手上拿到候選人的學曆認證，認證上寫了持證人，頒發機構，頒發時間等等，同時認證上，還寫有一個最重要的：認證編號！我們怎麼鑒別這張認證是的真偽呢？只要拿著這個認證編號上相關機構去查，如果認證上的持證人與現實的這個候選人一致，同時認證編號也能對應上，那麼就說明這個認證是真實的。

我們的用戶端能不能採用這個機制呢？像這樣：

可是，這個“第三方機構”到底是在哪呢？是一個遠端服務？不可能吧？如果是個遠端服務，整個互動都會慢了。所以，這個第三方機構的驗證功能只能放在用戶端的本地了。

用戶端本地怎麼驗證認證呢？

用戶端本地怎麼驗證認證呢？答案是認證本身就已經告訴用戶端怎麼驗證認證的真偽。

也就是認證上寫著如何根據認證的內容產生認證編號。用戶端拿到認證後根據認證上的方法自己產生一個認證編號，如果產生的認證編號與認證上的認證編號相同，那麼說明這個認證是真實的。

同時，為避免認證編號本身又被調包，所以使用第三方的私密金鑰進行加密。

這地方有些抽象，我們來個圖協助理解：

認證的製作。認證中的“編號產生方法MD5”就是告訴用戶端：你使用MD5對認證的內容求值就可以得到一個認證編號。

當用戶端拿到認證後，開始對認證中的內容進行驗證，如果用戶端計算出來的認證編號與認證中的認證編號相同，則驗證通過：

但是第三方機構的公開金鑰怎麼跑到了用戶端的機器中呢？世界上這麼多機器。

其實呢，現實中，瀏覽器和作業系統都會維護一個權威的第三方機構列表（包括它們的公開金鑰）。因為用戶端接收到的認證中會寫有頒發機構，用戶端就根據這個頒發機構的值在本地找相應的公開金鑰。

題外話：如果瀏覽器和作業系統這道防線被破了，就沒辦法。想想當年自己裝過的非常規XP系統，都害怕。

說到這裡，想必大家已經知道上文所說的，認證就是HTTPS中數位憑證，認證編號就是數位簽章，而第三方機構就是指數位憑證簽發機構（CA）。

CA如何頒發數位憑證給伺服器端的？

當我聽到這個問題時，我誤以為，我們的SERVER需要髮網絡請求到CA部門的伺服器來拿這個認證。?? 到底是我理解能力問題，還是。。

其實，問題應該是CA如何頒發給我們的網站管理員，而我們的管理員又如何將這個數位憑證放到我們的伺服器上。

我們如何向CA申請呢？每個CA機構都大同小異，我在網上找了一個：

拿到認證後，我們就可以將認證配置到自己的伺服器上了。那麼如何配置？這是具體細節了，留給大家google了。

也許我們需要整理一下思路

我們通過推算的方式嘗試還原HTTPS的設計過程。這樣，我們也就明白了為什麼HTTPS比HTTP多那麼多次的互動，為什麼HTTPS的效能會差，以及找到HTTPS的效能最佳化點。

而上面一大堆工作都是為了讓用戶端與伺服器端安全地協商出一個對稱式加密演算法。這就是HTTPS中的SSL/TLS協議主要乾的活。剩下的就是通訊時雙方使用這個對稱式加密演算法進行加密解密。

以下是一張HTTPS協議的真實互動圖（從網上copy的，忘了從哪了，如果侵權麻煩告知）：

能不能用一句話總結HTTPS？

答案是不能，因為HTTPS本身實在太複雜。但是我還是嘗試使用一段話來總結HTTPS:

HTTPS要使用戶端與伺服器端的通訊過程得到安全保證，必須使用的對稱式加密演算法，但是協商對稱式加密演算法的過程，需要使用非對稱式加密演算法來保證安全，然而直接使用非對稱式加密的過程本身也不安全，會有中間人篡改公開金鑰的可能性，所以用戶端與伺服器不直接使用公開金鑰，而是使用數位憑證簽發機構頒發的認證來保證非對稱式加密過程本身的安全。這樣通過這些機制協商出一個對稱式加密演算法，就此雙方使用該演算法進行加密解密。從而解決了用戶端與伺服器端之間的通訊安全問題。

好長的一段話。

原文轉自：http://blog.jobbole.com/110354/

https原理通俗瞭解