Tls
CertificateVerify 消息如何防止 TLS 1.3 中的 MITM 攻擊
在介紹 TLS 協議的第 9 章中，我遵循“Realworld Cryptography”一書，他們提到：
下列的
$$ authentication $$，伺服器可以使用其經過認證的長期密鑰對來簽署所有已接收和先前在所謂的消息中發送的握手
CertificateVerify消息。$$ … $$消息中的簽名CertificateVerify向客戶端證明了伺服器到目前為止所看到的內容。$$ … $$花點時間了解為什麼攻擊者無法在CertificateVerify消息存在的情況下替換伺服器的臨時公鑰。我查閱了更多文件，發現了以下描述
CertificateVerify：證書驗證消息是伺服器如何在不洩露私鑰本身的情況下證明證書私鑰的所有權：到此為止的整個握手都經過雜湊處理，並且使用私鑰對雜湊進行簽名。然後，客戶端可以計算相同的雜湊並使用公鑰驗證簽名。
據我了解：
- 客戶端和伺服器保留他們交換的 TLS 握手消息的“列表”。
- TLS 的身份驗證部分發生（為簡單起見，只說一面。）
- 伺服器計算交換的握手消息的雜湊值，並使用其長期私鑰對該雜湊值進行簽名。在消息中將雜湊發送回客戶端
CertificateVerify。- 客戶端擁有伺服器的公鑰。使用它來驗證
CertificateVerify.但是，如果我們假設真的是 MITM 攻擊者替換了伺服器的臨時 pub 密鑰，那麼他們也可以替換
CertificateVerify消息嗎？
攻擊者可以修改或替換 CertificateVerify 消息，但構成消息一部分的數字簽名不會通過驗證過程，除非：
- 攻擊者要麼能夠偽造與伺服器公鑰相關的簽名，要麼
- 如果他們能夠讓客戶端將不同的公鑰與伺服器相關聯。
不可偽造性是我們希望內置到所有數字簽名方案中的屬性，它應該阻止第一個子彈。第二個要點是防禦的，因為伺服器的公共簽名密鑰應該是長期驗證證書的主題，該證書具有由證書頒發機構的信任鏈簽署的伺服器的公鑰，該信任鏈錨定在由其公鑰分發的根證書頒發機構的簽名中作為驗證軟體（例如瀏覽器或作業系統）的一部分。只有當攻擊者能夠破壞這個信任鏈時，他們才能讓客戶端接受伺服器的替代公鑰。