面試準備——計算機網絡（https）

1、爲何要提出HTTPS？

HTTP的缺點：

• 明文通訊、不加密，可能被竊聽。
• 無身份驗證，可能遭遇假裝。
• 沒法證實報文的完整性，可能被篡改。

2、HTTPS = HTTP+加密（防竊聽）+認證（防假裝）+完整性保護（防篡改）

HTTPS（HTTP Secure，超文本傳輸安全協議），這裏的S是Secure的縮寫，可是我以爲理解爲HTTP over SSL更合適一些。

 

HTTPS實際上就是先用SSL創建一個安全通訊線路，而後在這條線路上進行HTTP通訊。至關於在HTTP和TCP之間增長了一層SSL層。

 

 

2.1 加密技術——防竊聽

近代加密技術中：加密算法是公開的，密鑰是保密的。（經過這種方法保持加密方法的安全性）

加密技術分爲兩類：一種叫共享密鑰加密，又稱對稱密鑰加密；一種叫公開密鑰加密，又稱非對稱密鑰加密。

 

共享密鑰加密：

加密和解密用同一個密鑰。

只要拿到密鑰就能夠破解全部用該密鑰加密的報文。

以共享密鑰方式加密時，必須先把密鑰安全地告訴對方。這就造成了一個悖論：沒有密鑰就不能加密，不能加密就可能會被竊聽，要想不被竊聽就要加密，可是沒有密鑰因此不能加密。

 

公開密鑰加密：

使用一對非對稱的密鑰，一把叫作私鑰，一把叫作公鑰。

公開密鑰能夠隨意發佈，任何人均可以得到。私有密鑰不能讓其餘任何人知道。

在這種方式下，發送密文的一方先向對方請求對方的公鑰，而後使用對方的公鑰對要發送的信息進行加密處理，對方收到被加密的信息後，再使用本身的私鑰進行解密。

公開密鑰至關於鎖，私有密鑰至關於鑰匙。我把鎖公開出去（這裏的公開出去是說只要向我請求我就把個人鎖送給你一份），想要給我發消息的就用這把鎖把消息鎖起來而後發給我，只有我有鑰匙，因此只有我能打開這把鎖看到要發給個人消息。

公開密鑰加密與共享密鑰相比多了一次通訊：要先請求對方的公鑰。所以公開密鑰加密效率低一些。

 

SSL使用的加密方法是共享密鑰加密。

 

HTTPS中的加密方式：混合密鑰加密 = 公開密鑰加密 + 共享密鑰加密

 

 

難道公開密鑰加密就是萬全之策了嗎？

答案是否認的。

其實和共享密鑰方式存在相同的問題，那就是密鑰傳遞過程的安全沒法保證，這一步是未經加密的，不論對共享密鑰方式仍是公開密鑰方式都是同樣的。

可是由於在共享密鑰方式中只有一個密鑰，這個密鑰既能夠用來加密也能夠用來解密，因此它一旦泄露就意味着整個加密體系被破解了，因此問題比較嚴重。

而公開密鑰方式中在密鑰傳遞過程當中傳遞的是公鑰，是發方用來在發送報文時加密的，不能用來解密因此不用擔憂其它密文會被破解，可是若是公鑰被篡改了，也就是公鑰若是不正確，那麼就會致使發方發出的信息收方沒法破解。 

 

2.2 服務器端的認證——公鑰證書

公鑰證書的提出是爲了保證 公開密鑰方式中 客戶端拿到的公鑰 就是 客戶端想要訪問的那臺服務器的公鑰。

 

CA：數字證書認證機構，能夠信賴的第三方機構。

 

使用公鑰證書的流程：

（1）服務器將本身的公開密鑰提交給CA，申請CA爲本身的公鑰頒發公鑰證書。

（2）CA自己有一個本身的私鑰，在判明申請者的身份以後，CA會對服務器提交的公鑰屬數字簽名（所謂的數字簽名就是用CA本身的私鑰對服務器提交的公鑰進行加密後的結果），而後向服務器頒發公鑰證書（公鑰證書 = 服務器本身的公鑰 + CA簽發的數字簽名）。

（3）客戶端向服務器請求後，服務器將公鑰證書返回給客戶端。客戶端拿到服務器的公鑰證書後，使用CA的公鑰驗證公鑰證書上的數字簽名（就是用CA的公鑰對數字簽名解密，而後看解密後的結果與公鑰證書中給的公鑰是否是一致），若是驗證經過就可使用公鑰證書中的公鑰進行後續的通訊了。

 

那麼問題又來了，客戶端怎麼保證本身得到的CA的公鑰是正確的呢？因此必需要保證先將CA的公鑰安全地交到客戶端手上，若是繼續用通訊的方式進行傳遞我相信這回是一個無限循環下去的問題。所以，多數瀏覽器會事先在內部植入經常使用認證機關的公開密鑰。

 

2.3 客戶端的認證——客戶端證書

客戶端證書的使用與公鑰證書原理相同。可是由於客戶端證書是要付費購買的，因此僅用於特殊用途的業務，好比網上銀行登陸時不只要求用戶輸入ID和密碼，還要求用戶的客戶端證書。

可是，所謂的客戶端證書不過也只是能證實客戶端實際存在，並不能證實用戶本人的真實有效性。這是由於客戶端證書這裏的「客戶端」針對的是擁有證書的這個終端這臺機器，而不是真實使用服務端服務的用戶這我的。

 

【可有可無的感想】寫到這吐槽一下，其實這一系列技術（不加密 --> 共享加密方式 --> 混合加密方式 --> 公鑰證書）就是 在不停地尋找不定因素中更加能夠信賴的對象。從「不加密 --> 共享加密方式」，是在徹底不肯定的網絡環境中認爲共享加密方式的密鑰是可信賴的。但其實共享加密方式的密鑰也不可信，因此有了混合加密方式，先對共享密鑰方式的密鑰用公開密鑰方式加密，在這裏是認爲公開密鑰方式的公鑰必定是可信賴的。然而公開密鑰方式的公鑰也可能會被篡改，所以又引入了公鑰證書來對公鑰進行認證，這裏是認爲CA必定是可信賴的。理論上來講，到此爲止，終於找到了一個看起來必定是可信賴的對象了，CA嘛，就是可信賴的第三方。可是，咱們又不得不問一句，CA真的必定可信嗎？歷史上的打臉時刻到來了，曾經有一家CA真的被黑客攻擊了......反正後續又提出了一系列的技術去再找更可信的對象，除非真的找到一個真的徹底能夠信賴的對象才能結束吧。（但問題是這個由機率肯定的世界真的有徹底肯定的因素嗎？）不過從好的方面看，咱們每次都能找到一個更可信的因素，就算達不到徹底可信，但咱們在不斷地逼近（從極限的思想來看）。

 3、HTTPS的通訊步驟

整理一下上面的內容，獲得一個HTTPS通訊的大體流程圖：

 

 

 

詳細步驟以下：

 

 

 

 

 

 

 

 4、爲何不一直使用HTTPS？

① 速度慢：

• 除去和TCP鏈接、發送HTTP請求與響應外，還必須進行SSL通訊 => 通訊量增長 => 通訊慢
• 在服務器和客戶端都須要進行加密和解密的運算處理 => 負載加強，大量消耗CPU及內存資源 => 處理速度慢

 ② 購買證書須要額外開銷

 

解決方法：非敏感信息用HTTP，包含我的信息等敏感數據時用HTTPS。