SSL TLS協議詳解 中 證書頒發機構

ssl/tls協議詳解(中)——證書頒發機構

ginove / 2018-08-05 18:53:13 / 瀏覽數 4732 技術文章

技術文章頂(2) 踩(0)

本文翻譯自：

解決這個問題的方案是採用證書頒發機構機制。當我們安裝瀏覽器或作業系統時，將會附有一組證書頒發機構，例如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的工作如下。假設伺服器需要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。

我們在理解金鑰交換過程的同時討論了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通訊。

如何在Windows中查詢證書頒發機構已頒發的證書

有時候需要看一下證書頒發機構已經頒發出去的證書，看看某個使用者或者某個計算機獲取過的證書有哪些。通常可以在證書頒發機構的mmc中檢視。對於測試環境或者剛開始用的ca來說，這樣檢視挺簡單的。但是對於用了一段時間，頒發了上千張證書的ca來說，就無法直接檢視了，需要用到view選單裡的filter。可以根...

SSL，TLS協議在OSI模型中的哪一層

ssl secure socket layer安全套接層 以及其繼承者tsl transport layer security 傳輸層安全 是為了網路通訊安全 提供安全及資料完整性的一種安全協議。tls與ssl在傳輸層對網路連線進行加密。ssl協議位於tcp ip協議與各種應用層協議之間，為資料通訊...

詳解HTTPS協議之加密 數字證書 工作模式

http協議本身是不安全的，解決安全問題我們可以採用加密 對稱加密演算法中，加密和解密使用的秘鑰是相同的。假設你和外賣 約定了乙個秘鑰，傳送請求的時候用這個秘鑰進行加密，外賣 用同樣的秘鑰進行解密，就算中間的黑客截獲請求，但是沒有秘鑰，所以還是破解不了。這樣是安全了，但是核心，秘鑰如何傳輸給對方呢，...