https證書被中間人截獲，信息會被監聽嗎？

假設A和B通信，B把證書傳給A。此時被中間人O攔截到證書，中間人備份一份后發給A。A驗證證書也無誤。那中間人不就可以拿證書進行中間人攻擊了嗎？

相當于O變成了A和B溝通的代理。O雖然改不了A的信息，但是感覺O可以偽造是A的信息。

我應該是理解錯了，但是不知道那個步驟沒理解。請各位大佬指出一下，謝謝。

這個小case太低估了https設計者的集體的智慧了。這些點他們早已想到并防范，還有咱們沒有想到的攻擊點，他們也想到了。當然基于TLS的https實現并不是100%安全，這種不安全性主要來自于TLS的Code不完美實現，而不是來自于TLS協議本身。

咱們以訪問知乎的主頁為例，當客戶端與知乎服務器建立TLS安全連接時，知乎的服務器會將自己的證書鏈推送給客戶端，通常是三張證書：

• CA證書（根證書，一級證書），用CA自己的私鑰給RA簽名并背書，自己給自己簽名（私鑰簽名）（1）
• RA證書（二級證書），包含RA明文公鑰，用RA自己的私鑰給知乎證書簽名并背書 （2）
• 知乎證書（葉子證書，三級證書），包含知乎的公鑰，知乎的公鑰由RA（私鑰）簽名并擔保 （3）

客戶端需要驗證這個證書鏈是否和本地操作系統信任證書有任何關聯，通常是這么驗證的：

• 客戶端根據2的RA公鑰，驗證3的簽名是否通過。說的直白一點就是，能否將簽名解密？如果可以，進入下一步，否則失敗。
• 客戶端根據1的CA公鑰，驗證2的簽名是否通過。如果可以，進入下一步，否則失敗。
• 客戶端使用1的CA公鑰，查詢本地信任CA證書數據庫，如果查詢到，則驗證通過，否則失敗。

終于來到題主的問題了，以上驗證過程只是驗證這個證書鏈是合法的，但是這個證書鏈是從知乎服務器發出的，還是第三方發出的，無法驗證，不是嗎？

如何確保這個證書鏈來自于知乎的服務器，而不是第三方呢？

很簡單，因為只有知乎服務器才擁有證書鏈里3的私鑰，第三方卻沒有，是嗎？

那只要在安全建立的過程，知乎服務器使用證書3的對應的私鑰，對某個關鍵信息簽名不就Okay了嗎？

客戶端收到這個有簽名的關鍵信息，只要用證書3的公鑰嘗試解密，成功則意味著簽名是知乎私鑰簽署的，消息報文來自于知乎服務器。否則就是偽造的，失敗。

對什么關鍵信息進行簽名呢？

當然對DH公鑰進行簽名最合理，因為DH算法的公鑰沒有簽名保護，很容易就被中間人攻擊了。此舉真是一舉兩得，既證明消息報文來自于知乎服務器，又間接保護了DH公鑰，來自于知乎服務器的DH公鑰。

雙方交換了DH公鑰、Nonce，雙方就可以推導用于加密http的對稱密鑰了，整個安全連接建立完成，https加密流量走起。

最后留給讀者一個問題，在TLS安全連接建立過程，客戶端并沒有證書（公鑰）也沒有自己的私鑰，會產生以下幾個潛在的問題：

• 客戶端的DH公鑰如何防范中間人攻擊？
• 客戶端發出的消息報文由于沒有簽名保護，如何防范中間人攻擊？比如中間人將加密算法修改成最容易破解的算法？

寫到這里突然想到本文的問題，如果第三方將知乎服務器的DH公鑰（知乎服務器私鑰簽名）保存下來，下一次直接replay是否可行？

同樣不可行，Replay是可以成功欺騙客戶端，但是第三方沒有知乎的DH私鑰啊，因為知乎服務器的DH私鑰不在網絡上傳輸，只保存在知乎服務器的內存里，而且一旦會話推出，這個DH私鑰就隨著內存釋放而消失了。