HTTPS的應用層協議

方案 5 - 非對稱加密 + 對稱加密 + 證書認證

在客戶端和服務器剛一建?連接的時候, 服務器給客戶端返回一個 證書，證書包含了之前服務端的公鑰, 也包含了網站的身份信息.

客戶端進行認證

當客戶端獲取到這個證書之后, 會對證書進行校驗(防止證書是偽造的).

? 判定證書的有效期是否過期

? 判定證書的發布機構是否受信任(操作系統中已內置的受信任的證書發布機構).

? 驗證證書是否被篡改: 從系統中拿到該證書發布機構的公鑰, 對簽名解密, 得到一個 hash 值(稱為數據摘要), 設為 hash1. 然后計算整個證書的 hash 值, 設為 hash2. 對比 hash1 和 hash2 是否相等. 如果相等, 則說明證書是沒有被篡改過的

中間人有沒有可能篡改該證書？

? 中間人篡改了證書的明文

? 由于他沒有 CA 機構的私鑰，所以無法 hash 之后用私鑰加密形成簽名，那么也就沒法辦法對篡改后的證書形成匹配的簽名

? 如果強行篡改，客戶端收到該證書后會發現明文和簽名解密后的值不一致，則說明證書已被篡改，證書不可信，從而終止向服務器傳輸信息，防止信息泄露給中間人

中間人整個掉包證書？

? 因為中間人沒有 CA 私鑰，所以無法制作假的證書(為什么？)

? 所以中間人只能向 CA 申請真證書，然后用自己申請的證書進行掉包

? 這個確實能做到證書的整體掉包，但是別忘記，證書明文中包含了域名等服務端認證信息，如果整體掉包，客戶端依舊能夠識別出來。

? 永遠記住：中間人沒有 CA 私鑰，所以對任何證書都無法進行合法修改，包括自己的

常見問題

為什么摘要內容在網絡傳輸的時候一定要加密形成簽名?

常見的摘要算法有: MD5 和 SHA 系列

以 MD5 為例, 我們不需要研究具體的計算簽名的過程, 只需要了解 MD5 的特點:

? 定?: 無論多?的字符串, 計算出來的 MD5 值都是固定?度 (16 字節版本或者32 字節版本)

? 分散: 源字符串只要改變一點點, 最終得到的 MD5 值都會差別很大.

? 不可逆: 通過源字符串生成 MD5 很容易, 但是通過 MD5 還原成原串理論上是不可能的.

正因為 MD5 有這樣的特性, 我們可以認為如果兩個字符串的 MD5 值相同,則認為這兩個字符串相同.

理解判定證書篡改的過程: (這個過程就好比判定這個身份證是不是偽造的身份證)

假設我們的證書只是一個簡單的字符串 hello, 對這個字符串計算 hash 值(比如 md5), 結果為 BC4B2A76B9719D91

如果 hello 中有任意的字符被篡改了, 比如變成了 hella, 那么計算的 md5 值就會變化很大. BDBD6F9CF51F2FD8

然后我們可以把這個字符串 hello 和 哈希值 BC4B2A76B9719D91 從服務器返回給客戶端, 此時客戶端如何驗證 hello 是否是被篡改過?

那么就只要計算 hello 的哈希值, 看看是不是 BC4B2A76B9719D91 即可.

所以被傳輸的哈希值不能傳輸明文, 需要傳輸密文.

所以，對證書明文(這里就是“hello”)hash 形成散列摘要，然后 CA 使用自己的私鑰加密形成簽名，將 hello 和加密的簽名合起來形成 CA 證書，頒發給服務端，當客戶端請求的時候，就發送給客戶端，中間人截獲了，因為沒有 CA 私鑰，就無法更改或者整體掉包，就能安全的證明，證書的合法性。最后，客戶端通過操作系統里已經存的了的證書發布機構的公鑰進行解密, 還原出原始的哈希值, 再進行校驗.

為什么簽名不直接加密，而是要先 hash 形成摘要?

? 縮?簽名密文的?度,加快數字簽名的驗證簽名的運算速度

總結

HTTPS 工作過程中涉及到的密鑰有三組.

第一組(非對稱加密): 用于校驗證書是否被篡改. 服務器持有私鑰(私鑰在形成 CSR 文件與申請證書時獲得), 客戶端持有公鑰(操作系統包含了可信任的 CA 認證機構有哪些, 同時持有對應的公鑰). 服務器在客戶端請求時，返回攜帶簽名的證書. 客戶端通過這個公鑰進行證書驗證, 保證證書的合法性，進一步保證證書中攜帶的服務端公鑰權威性。

第?組(非對稱加密): 用于協商生成對稱加密的密鑰. 客戶端用收到的 CA 證書中的公鑰(是可被信任的)給隨機生成的對稱加密的密鑰加密, 傳輸給服務器, 服務器通過私鑰解密獲取到對稱加密密鑰.

第三組(對稱加密): 客戶端和服務器后續傳輸的數據都通過這個對稱密鑰加密解密. 其實一切的關鍵都是圍繞這個對稱加密的密鑰. 其他的機制都是輔助這個密鑰工作的. 第?組非對稱加密的密鑰是為了讓客戶端把這個對稱密鑰傳給服務器. 第一組非對稱加密的密鑰是為了讓客戶端拿到第?組非對稱加密的公鑰