SSL/TLS協議詳解(中)——證書頒發機構
本文翻譯自：https://www.wst.space/ssl-part-3-certificate-authority/
上一篇中，我們討論了關於Diffie Hellman算法的SSL/TLS密鑰交換。我們最終認爲需要第三方來驗證服務器的真實性，並提出了證書頒發機構的機制。博客系列的最後兩部分的主要內容：
- TLS加密客戶端-服務器通信並阻止中間人攻擊。
- 編碼，散列和加密之間的區別
- TLS使用對稱密鑰加密來加密數據和公鑰基礎結構以交換對稱密鑰。
- 密鑰交換算法本身可能被攻擊者欺騙。因此，我們需要一個值得信賴的權威來驗證服務器的真實性。
證書頒發機構的需求
想象一下，客戶端瀏覽器正在嘗試與Web服務器通信，並且想要啓動TLS通道。從上面的最後一點來看，爲了證明服務器的身份，客戶端瀏覽器必須具有服務器的公鑰。但是，我們在瀏覽器中無法存儲要訪問的所有網站的公鑰，而且由於每分鐘都有新的網站出生，因此每分鐘都需要更新一次。
解決這個問題的方案是採用證書頒發機構機制。當我們安裝瀏覽器或操作系統時，將會附有一組證書頒發機構，例如DigiCert。當瀏覽器自帶DigiCert時，這意味着瀏覽器具有DigiCert的公鑰，網站可以向DigiCert索取證書和簽名。因此，DigiCert將使用DigiCerts私鑰在服務器證書上進行加密簽名。當我們發起連接時，服務器將發送嵌入了其公鑰的證書。由於瀏覽器具有DigiCert的公鑰，因此可以在服務器證書上驗證DigiCert的簽名，同時也說明證書上寫的服務器的公鑰是可信的。
如果您沒有完全理解這個概念，也請不要擔心。讓我們把這個過程細化再逐一分析。
數字簽名的定義
要理解證書頒發機構的概念，我們可以回顧幾十年前的傳統郵箱郵件系統並進行類比。想象一下，Alice擁有一家公司，而Bob則是該公司的員工，Alice想給Bob發一封機密郵件，作爲首席執行官的Alice，將起草郵件並將其放入郵箱，它將經過幾個郵局和幾個郵遞員並最終到達Bob的手中，Bob可以打開閱讀它，但Bob如何確保郵件真的來自Alice？這裏有兩種可能性：
1.攻擊者Eve可以使用任何內容起草郵件，將發件人地址設置爲類似於Alice的辦公室的地址並將其轉發給Bob。
2.Eve可以是中間人，例如中間郵局的員工，他可以在郵件到達Bob之前打開郵件，他甚至可以按照自己的意願重寫內容，然後將其重新發送給Bob。
在這兩種情況下，都無法確保收到的Alice郵件是否有效。這種時候我們會做什麼？查看簽名，Alice可以在郵件發佈給Bob時使用印章簽名，Alice的公司印章可用於驗證電子郵件的真實性和完整性。由於Alice的公司是公認的實體，如果郵件有簽名，我們可以信任它，這正是證書頒發機構所做的事情。
證書頒發機構的技術實現
我們知道PKI用於在TLS協議中交換會話密鑰，此過程可以稱爲身份驗證過程。爲了執行認證過程，服務器需要向客戶端發送公鑰，但是中間攻擊者可以獲取此公鑰並將其替換爲自己的公鑰，這是非常危險的，因爲客戶永遠不會知道公鑰在傳輸過程中是否被第三方篡改過。客戶端會在不知不覺中使用攻擊者的公鑰加密對稱密鑰並轉發出去，由於攻擊者持有相應的私鑰，他就可以解密並竊取數據。
爲了使客戶端信任所接收的公鑰，引入CA的概念。 CA的工作如下。假設服務器https://example.com 需要TLS證書。
1.服務器 example.com將從CA請求TLS證書，例如Digicert。
2.Digicert將爲example.com創建證書，證書將包含必要的數據，例如服務器名稱，服務器的公鑰等。
3.Digicert將創建數據（證書）的哈希值，並使用自己的私鑰對其進行加密。
4.瀏覽器和操作系統自帶Digicert等權威機構的公鑰。
5.當瀏覽器收到簽名證書時，它將使用公鑰從簽名生成哈希值，它還將使用證書中指定的散列算法生成數據（證書）的散列，如果兩個哈希值匹配，則簽名驗證成功並且證書是可信的。
6.現在瀏覽器可以使用證書中指定的example.com的公鑰繼續進行身份驗證過程。
在這裏，我們可以將Digicert稱爲Root CA.
如果攻擊者篡改證書會怎樣
收到證書後，瀏覽器將驗證服務器名稱、證書有效性、簽名等數據。想象一下，如果攻擊者使用他的自定義證書而不是example.com的證書，然後服務器名稱字段驗證將失敗，瀏覽器將立即斷開連接。
另一種情況是，如果攻擊者保留所有這些數據並用公鑰替換公鑰會發生什麼？在這種情況下，當瀏覽器嘗試從證書數據重新生成哈希時，由於數據被篡改，他將獲得不同的哈希值，從而數據和簽名計算出的哈希值將不匹配。
爲了繞過上述機制，攻擊者需要使簽名來匹配數據，爲了做到這點，他需要擁有Digicert的私鑰（最初爲example.com簽發並簽署了證書），所以攻擊者此時會失敗，因爲他可以創建的唯一簽名來自他的私鑰，我們的瀏覽器並不會信任這一點。瀏覽器的證書存儲區也不會有攻擊者的公鑰，並且在發生此類攻擊時會顯示證書異常，如下所示。
您可能已經注意到在嘗試爲瀏覽器設置代理時，發生私密錯誤是因爲代理工具在充當中間人，並向瀏覽器顯示自己的證書。如果您信任該證書，則可以點擊繼續；或者，您可以下載代理證書工具並將其添加到瀏覽器內的受信任機構列表中，這樣，您可以在代理工具中以純文本形式查看加密數據。
信任鏈
我們知道證書頒發機構是爲服務器創建並簽署證書，很少有組織從事這項工作，即Digicert，Geotrust，Comodo等。如果他們正在爲所有服務器簽署證書，則必須爲所有簽名使用相同的私鑰，如果它被盜，那麼所有的信任都會丟失。爲了解決這個問題並增加更多的平均信息量，引入了中間CA(intermediate CA)的概念。
這個想法很簡單。Charles是一個值得信賴的人，並曾經收到了Alice的簽名郵件，如果Bob看到Charles的簽名，他就會信任這封郵件。現在，Smith是Charles信任的另一個人，如果Smith代表Charles簽署了一封來自Alice的郵件，那麼Bob將不會一直相信它。這裏就出現了信任鏈：Bob相信Charles和Charles信任Smith，因此BOb可以信任Smith。類似地，intermediate CA是Root CA信任的證書頒發機構。 example.com的證書將由intermediate CA頒發，intermediate CA還將具有將由Root CA簽名的證書，並且只有Root CA的詳細信息會被存儲在瀏覽器的證書庫中。
因此，在證書驗證期間，瀏覽器信任Digicert Root CA和Digicert Root CA信任intermediate CA，因此瀏覽器可以信任intermediate CA。在下圖中，您可以看到層次結構，DigiCert SHA2 High Assurance Server CA是中間證書頒發機構和 DigiCert High Assurance EV Root CA。
此層次結構的另一個優點是Root CA無需始終在線。
數字簽名的數學算法
我們在理解密鑰交換過程的同時討論了Diffie-Hellman算法。類似地，也有許多算法可用於數字簽名，這寫會在服務器證書中指定。請參閱下面的example.com證書。
我不會多談核心的數學知識，因爲它很無聊，而且我也很菜。證書顯示帶有RSA加密的SHA-256。 RSA是一種流行的簽名算法，我會在這裏討論。與任何其他非對稱加密算法一樣，RSA也具有公鑰 - 私鑰對。這裏的區別在於，簽名（將其視爲加密）是通過使用intermediate CA的私鑰來完成的。並且簽名驗證（將其視爲解密）由瀏覽器使用相應的公鑰完成的。換句話說，RSA簽名不是RSA解密。如果您有興趣製作實用的RSA簽名，請參閱此處。
RSA將在簽署之前會對證書進行哈希處理，這有一個很重要的原因。如果您深入瞭解算法，您將知道如果數據長度超過其密鑰長度，RSA無法加密數據。假設我們使用2048位密鑰進行加密，那麼證書數據不應超過2048位，也就是255個字節，這並不總是可行的，因爲證書包含很多信息。因此，在加密之前，在證書上應用散列函數，該函數生成指定長度的唯一隨機字符串。在example.com的情況下，使用SHA-256哈希算法。如果您有興趣，可以進一步研究RSA的這種限制。
瀏覽器如何實際驗證給定服務器證書的有效性
我們知道服務器使用中級證書頒發機構的簽名，因此，在與瀏覽器通信時，服務器將共享兩個證書：一，包含服務器的公鑰，即實際的服務器證書；二，由Root CA頒發的intermediate CA證書。以下是驗證鏈的圖示。
在簽名驗證期間，瀏覽器首先使用已經存儲在瀏覽器中的Root CA的公鑰來驗證中間證書的數字簽名，如果成功，瀏覽器現在可以信任中間證書及其公鑰。現在使用此公鑰，瀏覽器將驗證原始服務器證書的簽名，該組織可以註冊爲intermediate CA，以便爲其域簽署證書。比如谷歌。
谷歌互聯網管理局G3是一個由全球認證Root CA -R2信任的intermediate CA，這意味着，Google可以使用此intermediate CA驗證其域名，由於谷歌瀏覽器是全球認證Root CA認證的，其他瀏覽器將信任它。必須注意的是，谷歌有權單獨簽署他們的域名。這可以防止Google爲Microsoft簽署證書。
後續
到目前爲止，我們已經討論了證書頒發機構和TLS協議的原理。在本系列的下一部分中，我們將實際檢查整個TLS通信。