在 SSL/TLS 握手期間，DHE 和 RSA 在什麼階段使用？
在 SSL/TLS 握手的哪個階段使用 DHE 和 RSA，當您可以使用 RSA 交換對稱密鑰（即 AES）以進行進一步通信時，使用預主密鑰的目的是什麼。我很困惑 DHE、AES 和 RSA 如何融合到 SSL/TLS 握手過程中。是否有純 RSA、純 DHE 或兩者的握手。
SSL/TLS 握手由一系列消息組成，這些消息一起進行密鑰交換和（通常）身份驗證。有關詳細資訊，請參閱rfc5246或其前身或維基百科。握手實際上產生一個“premaster secret”和一個“master secret”，然後用於派生多個密鑰：每個方向的加密密鑰（對於可能是 AES 或其他算法的算法），每個方向的 IV需要它的套件（這是 TLSv1.1 之前協議版本中的所有 CBC 套件，以及 TLSv1.2 中的一些 AEAD 套件），以及需要它的套件的每個方向的 HMAC 密鑰（除了 AEAD 套件之外的所有套件在 TLSv1.2 中）。請參閱如何在 SSL V3 中從主密鑰生成密鑰材料 和SSL/TLS 中客戶端和伺服器共享的四個不同秘密的目的是什麼？.
原始的並且仍然是一種常見的密鑰交換方法是 RSA，有時被強調為**“普通”RSA**或 kRSA。伺服器發送包含 RSA（公鑰）密鑰的證書；客戶端驗證證書並使用公鑰對隨機預主密鑰進行 RSA 加密。伺服器使用 Finished 消息證明正確的解密（並且被隱式驗證）。伺服器可以選擇請求客戶端認證；如果是這樣，則客戶端發送自己的證書並使用其匹配的私鑰簽署部分成績單，伺服器對其進行驗證和驗證，但這很少使用。除了可能的客戶端身份驗證之外，這是“純”RSA。
DHE（臨時模式下的 DH）與簽名證書結合使用，可以是 RSA 或 DSA。伺服器發送客戶端驗證的證書，以及在其證書下簽名的 DH 組和臨時公鑰；客戶端在同一組中生成其臨時密鑰並將其發送，如果使用客戶端身份驗證，則加上其證書和簽名。
還有一種方法可以在沒有證書和身份驗證的情況下使用 DH keyagreement，它實際上是短暫的，但 SSL/TLS 並沒有這樣稱呼它，而是將其稱為DH-anon。這通常是個壞主意。許多人認為只有被動竊聽者並認為他們只需要加密，但在當今的網際網路中，多種主動攻擊很普遍，如果您不使用身份驗證，您可能不安全。您可以將其視為“純”DHE，即使它不被稱為。
有橢圓曲線變體ECDHE（臨時、RSA 或 ECDSA 簽名}和 ECDH-anon。握手序列和安全屬性是相同的，只是實際的加密計算不同。這些在技術上是可選的，但實際上現在已廣泛實施並變得更受歡迎。
並且有使用長期的**“靜態”方法（DH 和 ECDH，沒有 E 或 anon）**
$$ EC $$DH 密鑰而不是臨時密鑰。這需要靜態密鑰的證書（以及組或曲線上的預先協議），這不太方便，特別是對於經典（非橢圓）DH，儘管 TLSv1.3 計劃添加可能會改變這一點的標準化 DH 組，以及這些方法似乎根本沒有在公共網路上使用。 最後，還有一些根本不使用公鑰的方法，包括預共享密鑰 (PSK) 和安全遠端密碼 (SRP)。這些基本上只在私有網路（或虛擬網路）中工作，在公共網路上看不到。
握手中不使用 AES 或其他數據密碼（如 3DES 或 RC4）。它用於握手後的數據。
與@mirabilos 相反
$$ EC $$DHE 方法在伺服器證書和客戶端證書下簽署臨時密鑰材料（如果使用客戶端身份驗證）。不適用於 -anon 方法，這些方法旨在不進行身份驗證。
您可以使用 RSA 交換密鑰，但問題是，它不能提供完美的前向安全性。如果您使用 RSA 進行密鑰交換，可能會發生這種情況。如果有人能夠儲存您的 SSL 會話並且他可以獲取伺服器私鑰，那麼他可以獲取 SSL 會話生成的密鑰。所以他可以解密整個 SSL 會話。
所以我們使用 Diffie Hellman（或 Elliptic Curve DH）進行密鑰交換。DH 密鑰交換的私鑰和公鑰是在那個時候生成的。所以它們以後無法複製。這裡 DH 沒有認證。因為該伺服器在發送給客戶端之前簽署了 DH 公鑰。這就是 DHE 和 RSA 的含義。它使用 DH 進行密鑰交換，使用 RSA 進行簽名。這裡 AES 意味著最終生成了 AES 密鑰。此連結將為您提供更多資訊