TLS-X509 和雙向認證

無論是在微服務開發還是使用 kubernetes 的過程中，我們都會經常用到 TLS 協議來保證客戶端和服務端之間的安全通信！

接下來的故事解釋了 TLS 和 X509 證書要解決的問題。

最近，我不得不在 MySQL 主、備服務器之間設置雙向 TLS 身份認證，這讓我第一次有機會真正地設置和運行 CA，並實現雙向身份認證。

這是個非常不錯的經歷，我想在這裏總結並擴展一下我學到的一些東西。首先聲明：這並不是爲了 100% 準確地反映規範而寫的。相反，爲了抽象在某些地方做了簡化。希望在提及術語的地方有鏈接，可以找到更具體的含義。

數據安全問題

在定義計算機如何通信時，可以合理地假設信息將從一臺計算機直接發送到另一臺計算機。如下圖計算機 “Alice” 向計算機 “Bob” 發送一個訪問網站的請求:

計算機之間如何通信

然而，實際情況並非如此。兩臺電腦直接連接在一起是極其少見的；通常，中間有許多計算機 (通常稱爲“路由器” 或“防火牆”或任何數量的其他類似設備”)。它看起來更像:

計算機實際通信情況

這給計算機 Alice 和 Bob 帶來了一個問題。首先，他們不能確定 Alice 和 Bob 之間的計算機沒有記錄正在說什麼，如果 Alice 向計算機 “Bob” 發送一條消息，“Bob”不能確定看似由計算機 “Alice” 發送的消息，實際上真的是由 “Alice” 發送的，也不能確定收到的消息是未經串改的。
幸運的是，有一種機制可以解決這個問題。

TLS（傳輸層安全協議）

爲了解決上面的問題，自 1996 年以來，傳輸層安全協議 (TLS) 及其前身安全套接字層 (SSL) 就已經存在。如前所述，有兩組問題需要解決:

確保數據轉發過程不被讀取

爲了確保數據不被位於網絡連接中間的計算機讀取，發送數據需要加密。加密是對信息進行編碼的過程，只有那些應該能夠閱讀和理解它的人才能閱讀和理解它。爲了來回傳遞信息，兩臺計算機需要決定如何對數據進行加解密，以便只有它們能理解，而中間的計算機不能。

接着上面的例子，爲了和 Bob 安全發送數據，Alice 需要知道一些加密數據的方法，而且只有 Bob 可以解密。這是一個雞和蛋的問題；如何共享這個加密方法，仍然是一個難題。解決方案在於一個名爲 “公鑰加密” 的過程。

不需要深入瞭解內部是如何工作的，只需知道 Bob 有一個用來編解碼信息的密鑰。Bob 的密鑰分成兩部分:

第一步，Alice 需要請求 Bob 的公鑰。這個過程被稱爲非對稱加密，看起來像這樣:

Alice 和 Bob 之間的計算機無法解碼公匙加密的信息

但是，這個過程有一個缺點：不能實現 Bob 向 Alice 發送只有 Alice 能讀到的消息。爲了回覆 Alice 的消息，Bob 需要一個只有 Alice 能理解的密鑰。

Alice 知道她可以發送只有 Bob 能解碼的信息。所以，她可以利用這一點向 Bob 發送一些祕密信息，這些信息可以被 Alice 和 Bob 用來對彼此之間的信息進行加密。

該祕密信息就是對稱密鑰。這個密鑰在 Alice 和 Bob 之間共享，可以用來解碼任何一方發送的消息。這就實現了兩種方式的加密連接。

上圖中：Alice 首先拿到 Bob 的公鑰，然後通過公鑰加密向 Bob 發送對稱加密的密匙，之後就使用對稱密匙加密要發送的信息。這裏非對稱加密的過程，目的是爲了安全地共享後面要用的對稱加密密匙。因此、不用擔心是否有人在監聽他們的連接。只有 Alice 和 Bob 有用於解碼這些消息的對稱密鑰!

但是，這個過程有一個缺陷：我們如何確保 Bob 就是 Bob?

確認 Bob 是本人（服務端身份驗證）

在上述例子中，我們知道 Alice 通過計算機網絡與 Bob 對話。然而，如果其中一臺計算機突然開始假裝是 Bob，會發生什麼?

如果 Alice 事先不認識 Bob，那麼她不可能知道 “Bob” 就是“Bob”。Alice 會和任何假裝是 Bob 的人建立一個加密連接。確實，雖然這裏沒有顯示，對 Bob 來說中間的一個計算機可以僞裝成 Alice，而對 Alice 來說它可以是 Bob！這就是所謂的“中間人攻擊”。

然而，TLS 標準有一部分是設計用來解決這個問題的。具體來說，當 Alice 第一次向 Bob 表示她想通過一個加密連接開始對話時，她不僅要求 Bob 提供公鑰，而且要求他提供一個證明他是誰的證書 (X.509 證書)。然後，Alice 向一個稱爲“證書權威機構” 的可信顧問諮詢 Bob 是否合法，並根據權威機構的認證決定是否繼續通信。

通過 CA 驗證 Bob 身份

如果證書不是由權威機構擔保的，那麼 Alice 將簡單地拒絕連接。

證書未通過 CA 的驗證結束連接

確認 Alice 是本人（客戶端身份驗證）

對 Alice 來說，現在通信是愉快的，而且相當安全。她知道與她交談的 Bob 是真正的 Bob，只有她和 Bob 可以看到發送的信息。然而，Bob 不能保證 Alice 的身份。
每個連接都有兩個方面：

驗證服務端身份是一個非常常見的操作。的確，當你瀏覽這篇文章時，很可能你的瀏覽器就驗證了你看到的博客網站就是它聲稱的那個博客網站。驗證 Alice 身份實際上是一個不太常見的操作，但通常稱爲 “Mutual TLS authentication”，因爲 Alice 和 Bob 都需要驗證。

考慮這樣一個場景，Bob 希望從 Alice 那裏得到一些敏感的數據，可能是醫療數據或類似的數據。然後 Bob 會處理這些數據然後對 Alice 的情況做出診斷。在這種情況下，Bob 肯定想確定 Alice 是真實的 Alice，而不是編造假的診斷數據!

幸運的是，前面提到的 TLS 標準可以很容易地擴展爲包括對 Alice 和 Bob 相同的驗證過程:

現在，Alice 和 Bob 都能保證他們就是他們所聯繫的那個人 (由他們的證書權威機構擔保)，並且連接是加密的，這個連接可以說是非常安全的。

總結：

傳輸層安全性協議 (Transport Layer Security, TLS) 和 X.509 證書在第一次遇到時看起來像是很神奇的東西，以某種方式提供安全性，但不清楚具體如何提供安全性或爲什麼提供安全性。在使用了幾次並進行必要的調試之後，讓所有內容正確地通信就變得更簡單了。希望這篇文章能夠讓你對理解 HTTPS 連接變得更加簡單。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/xD7wDsrwvB-Vq09kVcLUlQ

猜你喜歡