面試準備——計算機網路(https)

山斗發表於2021-03-06

一、為什麼要提出HTTPS?

HTTP的缺點:

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

二、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真的被黑客攻擊了......反正後續又提出了一系列的技術去再找更可信的物件,除非真的找到一個真的完全可以信賴的物件才能結束吧。(但問題是這個由概率確定的世界真的有完全確定的因素嗎?)不過從好的方面看,我們每次都能找到一個更可信的因素,就算達不到完全可信,但我們在不斷地逼近(從極限的思想來看)。

 三、HTTPS的通訊步驟

整理一下上面的內容,得到一個HTTPS通訊的大致流程圖:

 

 

 

詳細步驟如下:

 

 

 

 

 

 

 

 四、為什麼不一直使用HTTPS?

速度慢

  • 除去和TCP連線、傳送HTTP請求與響應外,還必須進行SSL通訊 => 通訊量增加 => 通訊慢
  • 在伺服器和客戶端都需要進行加密和解密的運算處理 => 負載增強,大量消耗CPU及記憶體資源 => 處理速度慢

 ② 購買證書需要額外開銷

 

解決方法:非敏感資訊用HTTP,包含個人資訊等敏感資料時用HTTPS。

相關文章