伺服器密鑰交換生成上的公鑰與伺服器證書上的公鑰
了解 TLS 1.2 和 TLS 1.3 之間的區別。我被困在過去對 TLS 的理解和我正在研究的目前參考中：
據我所知，證書與所有者的公鑰一起使用，其公鑰用於客戶端和伺服器之間的密鑰交換以生成長期預共享密鑰。
但是當我研究TLS 1.2 中的階段伺服器密鑰交換生成時，我對這種理解感到困惑。
它說從伺服器派生的用於密鑰交換的公鑰不是附加的，而是從隨機數派生的新的 $ 2^{256} -1 $ 作為私鑰。
哪一個是對的？我在不同的參考文獻中聽說過這兩種情況。這也讓我產生了另一個關於通過證書防止中間人攻擊的問題，如下所示：
如果使用者的瀏覽器被欺騙性的 DNS 解析器篡改，該解析器返回虛假伺服器的 IP 地址，該地址服務於與從真實網站獲取的證書相同的網站主機名。如果 TLS 握手在證書驗證和密鑰交換中使用兩個不同的密鑰對，瀏覽器如何驗證完整性？
TLS ≤1.2 允許不同類型的握手，其中密鑰交換和身份驗證依賴於不同的機制。握手的類型由密碼套件的選擇決定。您連結到的頁面說明了最常見的類型，其中密鑰交換和伺服器身份驗證獨立工作。這種類型的握手是名稱中帶有 ECDHE 或 DHE 的密碼套件使用的握手類型。
對於這種類型的握手，密鑰交換使用一個[橢圓曲線] D iffie - Hellman密鑰協商算法和一個臨時**（****即**一次性）密鑰。為了生成ServerKeyExchange消息，伺服器生成一個（EC）DH私鑰，ServerKeyExchange消息包含對應的公鑰。客戶端對 ClientKeyExchange 消息執行相同的操作。然後，雙方使用自己的私鑰和對方的公鑰執行Diffie-Hellman密鑰協商算法，以生成共享密鑰。通過DH的設計，雙方生成相同的共享秘密。此共享密鑰是 TLS 協議的預主密鑰。
在您連結中的特定範例中，伺服器選擇 X25519 組作為密鑰協議。對於這個特定的組，私鑰是一個整數 $ 0 $ 和 $ 2^{256}-1 $ .
這些都不允許客戶端知道它與誰交換數據。這來自 ServerKeyExchange 消息的不同部分：簽名。伺服器發送迄今為止使用其私鑰生成的重要握手數據的簽名。具體來說，簽名數據包括來自ClientHello消息的客戶端nonce、來自ServerHello消息的伺服器nonce和DH公鑰。以前，伺服器發送包含其證書的證書消息。客戶驗證：
- 伺服器發送的簽名是適當的握手消息的正確簽名，使用與伺服器發送的證書中的公鑰對應的私鑰進行。
- 證書由客戶端信任的證書頒發機構 (CA) 簽名，或者更一般地說，存在從受信任的 CA 到伺服器證書的信任鏈。
- 證書中的主題名稱與客戶端嘗試聯繫的伺服器名稱相匹配。
欺騙 DNS 記錄的中間人攻擊者將無法通過所有這些驗證。
- 攻擊者可以發送預期的證書並從過去觀察到的與合法伺服器的交換中重放一個好的簽名，但是這個簽名將不正確，因為握手消息包含客戶端發送的隨機數。
- 攻擊者可以將 ClientHello 消息轉發給合法伺服器，獲取合法伺服器的 ServerExchangeMessage 並將其轉發給客戶端。由於該消息中的簽名包括伺服器選擇的 DH 公鑰，因此攻擊者將無法找到共享密鑰。在這種情況下，如果攻擊者保持原封不動地轉發雙方的消息，則交換可以通過，但攻擊者將無法解密消息或修改它們而不被發現。由於攻擊者無法違反 TLS 協議的預期安全屬性，他們實際上並沒有攻擊任何東西：他們只是一個 TCP 路由器。
- 攻擊者可以發送預期的證書和使用自己的私鑰生成的簽名，但是簽名將不正確，因為攻擊者需要合法伺服器的私鑰來生成正確的簽名。
- 攻擊者可以發送包含虛假數據的證書，但隨後客戶端會檢測到該證書內部不一致或該證書未由其信任的 CA 簽名。
- 攻擊者可以發送由客戶端信任的 CA 製作的有效證書，但隨後（假設 CA 已正確完成其工作）該證書將包含攻擊者擁有的主題名稱，而不是客戶端嘗試的主題名稱聯繫。