看圖學HTTPS

leocoder發表於2018-05-21

前言

之前說到HTTPS，在我的概念中就是更安全，需要伺服器配置證書，但是到底什麼是HTTPS，為什麼會更安全，整套流程又是如何實現的，在腦子裡沒有具體的概念。所以，我花了幾天的時間，通過參考一些文章，學習了HTTPS整套機制的實現，想要通過一篇文章把我學習到的東西總結出來，讓更多之前不清楚HTTPS到底是什麼的同學有一個入門的理解。

我看過的很多文章都是通過大量的文字和協議圖來解釋，但往往會讓人感覺有點枯燥，這篇文章我會通過一幅幅流程圖，形象的說明從HTTP到HTTPS的演變過程，讓大家可以更容易理解一些。當然，這個只是入門級，如果想要學習更深入的HTTPS的知識，還是要深入到一個個協議裡面，看一些大部頭，才可以達到完全理解的效果。

本文也會同步到我的個人網站。

正文

HTTP是什麼樣的？

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

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

加個密呢？

因為上圖中資料是明文傳輸的，我們能想到最簡單的提高安全性的方法就是在傳輸前對資料進行加密，如下圖：

這種加密方式叫做：對稱加密。加密和解密用同一個祕鑰的加密方式叫做對稱加密。

好了，我們對資料進行加密了，問題解決了嗎？

多個客戶端怎麼辦？

這是一個客戶端，但是在WWW上，是成千上萬的客戶端，情況會怎樣呢？

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

想一想，是不是還有別的辦法呢？

相信大家都可以想到，如果對每一個客戶端都用不同的祕鑰進行傳輸是不是就解決這個問題了：

對稱加密祕鑰如何傳輸？

我們對每個客戶端應用不同的對稱加密祕鑰，那麼這個祕鑰客戶端或者服務端是如何知道的呢，只能是在一端生成一個祕鑰，然後通過HTTP傳輸給另一端：

那麼這個傳輸祕鑰的過程，又如何保證加密？如果被中間人攔截，祕鑰也會被獲取。也許你會說，對祕鑰再進行加密，那又如何保證對祕鑰加密的過程，是加密的呢？

好像我們走入了 while(1)，出不來了。

非對稱加密

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

私鑰只儲存在伺服器端，公鑰可以傳送給所有的客戶端。

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

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

MITM：Man-in-the-MiddleAttack

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

第三方認證

公鑰被掉包，是因為客戶端無法分辨傳回公鑰的到底是中間人，還是伺服器，這也是密碼學中的身份驗證問題。

在HTTPS中，使用 證書 + 數字簽名 來解決這個問題。

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

數字證書 = 網站資訊 + 數字簽名

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

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