接下來的故事解釋了TLS和X509證書解決的問題。
最近，我不得不在MySQL主、備服務器之間設置雙向TLS身份認真，這讓我第一次有機會真正地設置和運行CA，并實現(xiàn)雙向身份認證。
這是個非常不錯的經(jīng)歷，我想在這里總結并擴展一下我學到的一些東西。首先聲明：這并不是為了100%準確地反映規(guī)范而寫的。相反，為了抽象在某些地方做了簡化。希望在提及術語的地方有鏈接，可以找到更具體的含義。
數(shù)據(jù)安全問題
在定義計算機如何通信時，可以合理地假設信息將從一臺計算機直接發(fā)送到另一臺計算機。如下圖計算機“Alice”向計算機“Bob”發(fā)送一個訪問網(wǎng)站的請求:
然而，實際情況并非如此。兩臺電腦直接連接在一起是極其少見的；通常，中間有許多計算機(通常稱為“路由器”或“防火墻”或任何數(shù)量的其他類似設備”)。它看起來更像:
這給計算機Alice和Bob帶來了一個問題。首先，他們不能確定Alice和Bob之間的計算機沒有記錄正在說什么，如果Alice向計算機“Bob”發(fā)送一條消息，“Bob”不能確定看似由計算機“Alice”發(fā)送的消息，實際上真的是由“Alice”發(fā)送的，也不能確定收到的消息是未經(jīng)串改的。
幸運的是，有一種機制可以解決這個問題。
TLS（傳輸層安全協(xié)議）
為了解決上面的問題，自1996年以來，傳輸層安全協(xié)議(TLS)及其前身安全套接字層(SSL)就已經(jīng)存在。如前所述，有兩組問題需要解決:
確保數(shù)據(jù)轉發(fā)過程不被讀取
為了確保數(shù)據(jù)不被位于網(wǎng)絡連接中間的計算機讀取，發(fā)送數(shù)據(jù)需要加密。加密是對信息進行編碼的過程，只有那些應該能夠閱讀和理解它的人才能閱讀和理解它。為了來回傳遞信息，兩臺計算機需要決定如何對數(shù)據(jù)進行加解密，以便只有它們能理解，而中間的計算機不能。
接著上面的例子，為了和Bob安全發(fā)送數(shù)據(jù)，Alice需要知道一些加密數(shù)據(jù)的方法，而且只有Bob可以解密。這是一個雞和蛋的問題；如何共享這個加密方法，仍然是一個難題。解決方案在于一個名為“公鑰加密”的過程。
不需要深入了解內部是如何工作的，只需知道Bob有一個用來編解碼信息的密鑰。Bob的密鑰分成兩部分:
- 公共部分：用于加密數(shù)據(jù)；
- 私有部分：用于解碼數(shù)據(jù)；
這就允許Bob將這個密鑰的公共部分發(fā)送給Alice，Alice可以使用它來編碼和發(fā)送只有Bob可以讀取的信息。這些密鑰也稱為“密鑰”一個公鑰和一個私鑰。
第一步，Alice需要請求Bob的公鑰。這個過程被稱為非對稱加密，看起來像這樣:
但是，這個過程有一個缺點：不能實現(xiàn)Bob向Alice發(fā)送只有Alice能讀到的消息。為了回復Alice的消息，Bob需要一個只有Alice能理解的密鑰。
Alice知道她可以發(fā)送只有Bob能解碼的信息。所以，她可以利用這一點向Bob發(fā)送一些秘密信息，這些信息可以被Alice和Bob用來對彼此之間的信息進行加密。
該秘密信息就是對稱密鑰。這個密鑰在Alice和Bob之間共享，可以用來解碼任何一方發(fā)送的消息。這就實現(xiàn)了兩種方式的加密連接。
上圖中：Alice首先拿到Bob的公鑰，然后通過公鑰加密向Bob發(fā)送對稱加密的密匙，之后就使用對稱密匙加密要發(fā)送的信息。這里非對稱加密的過程，目的是為了安全地共享后面要用的對稱加密密匙。因此、不用擔心是否有人在監(jiān)聽他們的連接。只有Alice和Bob有用于解碼這些消息的對稱密鑰!
但是，這個過程有一個缺陷：我們如何確保Bob就是Bob?
確認Bob是本人（服務端身份驗證）
在上述例子中，我們知道Alice通過計算機網(wǎng)絡與Bob對話。然而，如果其中一臺計算機突然開始假裝是Bob，會發(fā)生什么?
如果Alice事先不認識Bob，那么她不可能知道“Bob”就是“Bob”。Alice會和任何假裝是Bob的人建立一個加密連接。確實，雖然這里沒有顯示，對Bob來說中間的一個計算機可以偽裝成Alice，而對Alice來說它可以是Bob！這就是所謂的“中間人攻擊”。
然而，TLS標準有一部分是設計用來解決這個問題的。具體來說，當Alice第一次向Bob表示她想通過一個加密連接開始對話時，她不僅要求Bob提供公鑰，而且要求他提供一個證明他是誰的證書(X.509證書)。然后，Alice向一個稱為“證書權威機構”的可信顧問咨詢Bob是否合法，并根據(jù)權威機構的認證決定是否繼續(xù)通信。
如果證書不是由權威機構擔保的，那么Alice將簡單地拒絕連接。
確認Alice是本人（客戶端身份驗證）
對Alice來說，現(xiàn)在通信是愉快的，而且相當安全。她知道與她交談的Bob是真正的Bob，只有她和Bob可以看到發(fā)送的信息。然而，Bob不能保證Alice的身份。
每個連接都有兩個方面：
- 客戶端：上面的例子指的是Alice，她先發(fā)起消息。
- 服務點：上面的例子指的是Bob，向客戶端返回消息。
驗證服務端身份是一個非常常見的操作。的確，當你瀏覽這篇文章時，很可能你的瀏覽器就驗證了你看到的博客網(wǎng)站就是它聲稱的那個博客網(wǎng)站。驗證Alice身份實際上是一個不太常見的操作，但通常稱為“Mutual TLS authentication”，因為Alice和Bob都需要驗證。
考慮這樣一個場景，Bob希望從Alice那里得到一些敏感的數(shù)據(jù)，可能是醫(yī)療數(shù)據(jù)或類似的數(shù)據(jù)。然后Bob會處理這些數(shù)據(jù)然后對Alice的情況做出診斷。在這種情況下，Bob肯定想確定Alice是真實的Alice，而不是編造假的診斷數(shù)據(jù)!
幸運的是，前面提到的TLS標準可以很容易地擴展為包括對Alice和Bob相同的驗證過程:
現(xiàn)在，Alice和Bob都能保證他們就是他們所聯(lián)系的那個人(由他們的證書權威機構擔保)，并且連接是加密的，這個連接可以說是非常安全的。
總結：
傳輸層安全性協(xié)議(Transport Layer Security, TLS)和X.509證書在第一次遇到時看起來像是很神奇的東西，以某種方式提供安全性，但不清楚具體如何提供安全性或為什么提供安全性。在使用了幾次并進行必要的調試之后，讓所有內容正確地通信就變得更簡單了。希望這篇文章能夠讓你對理解HTTPS連接變得更加簡單。
