http存在的隱患

HTTP是屬于應用層的協議，它是基于TCP/IP的，所以它只是規定一些要傳輸的內容，以及頭部信息，然后通過TCP協議進行傳輸，依靠IP協議進行尋址，通過一幅最簡單的圖來描述：

客戶端發出請求，服務端進行響應，就是這么簡單。在整個過程中，沒有任何加密的東西，所以它是不安全的，中間人可以進行攔截，獲取傳輸和響應的數據，造成數據泄露。

對稱加密

對于這種情況，我們想到的最直接的辦法就是對數據加密

這種加密方式叫做：對稱加密。 加密和解密用同一個秘鑰的加密方式叫做對稱加密。但是對稱加密卻解決不了任何問題，比如多個客戶端怎么辦？

為所有的客戶端都應用同一個秘鑰A，這種方式很顯然是不合理的，破解了一個用戶，所有的用戶信息都會被盜取。

但是如果每個客戶端 都準備一個密鑰也不是很現實，服務端需要維護的太多。

另外對稱加密還存在一個問題就是對稱加密的秘鑰也需要傳輸，如果在傳輸秘鑰的過程中被攔截，秘鑰也會被獲取，也是非常不安全的。

非對稱加密

在對稱加密的路上走不通了，我們換個思路，還有一種加密方式叫非對稱加密，比如RSA。 非對稱加密會有一對秘鑰：公鑰和私鑰。 公鑰加密的內容，只有私鑰可以解開，私鑰加密的內容，所有的公鑰都可以解開（當然是指和秘鑰是一對的公鑰）。

私鑰只保存在服務器端，公鑰可以發送給所有的客戶端。

在傳輸公鑰的過程中，肯定也會有被中間人獲取的風險，但在目前的情況下，至少可以保證客戶端通過公鑰加密的內容，中間人是無法破解的，因為私鑰只保存在服務器端，只有私鑰可以破解公鑰加密的內容。

現在我們還存在一個問題，如果公鑰被中間人拿到篡改呢： MITM：Man-in-the-MiddleAttack

客戶端拿到的公鑰是假的，如何解決這個問題？

第三方認證

公鑰被掉包，是因為客戶端無法分辨傳回公鑰的到底是中間人，還是服務器，這也是密碼學中的身份驗證問題。 在HTTPS中，使用 證書 + 數字簽名 來解決這個問題。

這里假設加密方式是MD5，將網站的信息加密后通過第三方機構的私鑰再次進行加密，生成數字簽名。

數字證書 = 網站信息 + 數字簽名

假如中間人攔截后把服務器的公鑰替換為自己的公鑰，因為數字簽名的存在，會導致客戶端驗證簽名不匹配，這樣就防止了中間人替換公鑰的問題。

瀏覽器安裝后會內置一些權威第三方認證機構的公鑰，比如VeriSign、Symantec以及GlobalSign等等，驗證簽名的時候直接就從本地拿到相應第三方機構的公鑰，對私鑰加密后的數字簽名進行解密得到真正的簽名，然后客戶端利用簽名生成規則進行簽名生成，看兩個簽名是否匹配，如果匹配認證通過，不匹配則獲取證書失敗。

為什么要有簽名？

大家可以想一下，為什么要有數字簽名這個東西呢？

第三方認證機構是一個開放的平臺，我們可以去申請，中間人也可以去申請呀：

如果沒有簽名，只對網站信息進行第三方機構私鑰加密的話，會存在下面的問題：

因為沒有認證，所以中間人也向第三方認證機構進行申請，然后攔截后把所有的信息都替換成自己的，客戶端仍然可以解密，并且無法判斷這是服務器的還是中間人的，最后造成數據泄露。

對稱加密

在安全的拿到服務器的公鑰之后，客戶端會隨機生成一個對稱秘鑰，使用服務器公鑰加密，傳輸給服務端，此后，相關的 Application Data 就通過這個隨機生成的對稱秘鑰進行加密/解密，服務器也通過該對稱秘鑰進行解密/加密：

整體流程圖

HTTPS = HTTP + TLS/SSL

HTTPS中具體的內容還有很多，可以通過下圖做一個參考：

總結

HTTPS就是使用SSL/TLS協議進行加密傳輸，讓客戶端拿到服務器的公鑰，然后客戶端隨機生成一個對稱加密的秘鑰，使用公鑰加密，傳輸給服務端，后續的所有信息都通過該對稱秘鑰進行加密解密，完成整個HTTPS的流程。

好啦！今天分享到這里就結束了，希望大家持續關注馬哥教育官網，每天都會有大量優質內容與大家分享！聲明:文章轉載于網絡，版權歸原作者所有，如有侵權請及時聯系刪除！