TLS-DHE 中的質詢/響應和證書驗證在哪裡
我們的任務是辨識 TLS-DHE 中的以下三個組件：
- Diffie Hellman 密鑰交換
我相當肯定這部分可以在 SKE 和 CKE 的交換中找到，因為它們包含帶有簽名的公鑰，並且可以被另一方用來派生共享密鑰
- 挑戰/回應
我無法辨識這部分。由於這部分通常是您在交換密鑰之前要做的事情，因此我認為它只能出現在帶有 CH 的部分中。但是，我看不到 CH（挑戰？）對伺服器 S 來說是一個挑戰，因為通常挑戰是通過使用私人資訊來解決的
- 證書驗證
我知道證書由公鑰和數字簽名組成，但是如何在沒有建立共享密鑰的情況下在這裡對證書進行身份驗證？我在這裡也沒有看到任何證書頒發機構，所以我一無所知
Diffie Hellman 密鑰交換
那作業 $ y\overset{s}\gets{\mathbb{Z}_q} $ 生成一個隨機的 48 字節值（不知道是什麼 $ s $ 和 $ q $ 在這裡）在整個握手過程中對伺服器來說都是私密的。
伺服器使用生成器使用其喜歡的 DH 組 $ g $ 和模 $ p $ 併計算 $ Y\gets{g^y} \mod p $ 因為它的公鑰和所有這些“參數” $ p $ , $ g $ 和 $ Y $ 被送入 $ SKE $ 以明文形式向客戶端發送消息。
客戶端生成自己的 48 字節隨機私有密鑰 $ x\overset{s}\gets{\mathbb{Z}_q} $ 並使用 DH 組的 $ g $ 和 $ p $ 在伺服器中收到 $ SKE $ 消息計算並發送回其 $ X\gets{g^x} \mod p $ 公鑰在 $ CKE $ 資訊。
客戶端和伺服器都準備好計算 premaster secret $ pms = CDH(X, Y) = g^{xy}\mod p $ 與客戶一起使用 $ pms = Y^x\mod p $ 和伺服器計算 $ pms = X^y\mod p $ 並且都達到了一個共同的預主秘密 $ pms $ MITM 無法計算，因為 CDH 在計算上難以處理，並且兩者 $ x $ 和 $ y $ 不通過電線發送。
挑戰/回應
這個 $ r_C\overset{s}\gets{0,1}^{224} $ 生成長度為 224 位的客戶端隨機數（對於 TLS 必須為 256 位），對於 $ r_S $ 伺服器隨機。
這兩個都用於生成主密鑰 $ ms $ 來自預知秘訣 $ pms $ 使用 TLS $ PRF $ 像這樣的功能 $ ms = PRF_{pms}(l_1, r_C, r_S) $ 在哪裡 $ l_1 $ 是一個類似
master secret或extended master secret純文字的標籤，並且 $ pms $ 被饋送作為啟動鍵 $ HMAC $ 用於 $ PRF $ .如果 $ pms $ 在雙方不匹配然後 $ HMAC $ 和 $ PRF $ 會產生不同的主秘 $ ms $ . 如果這些反過來與擴展密鑰不匹配，則雙向對稱加密的 IV 也將不匹配，因此受保護的 $ FIN_C $ 和 $ FIN_S $ 因此，消息將無法通過 MAC 身份驗證檢查。
因此，如果攻擊者重放客戶端流量，不同的 $ r_S $ 會阻止 $ ms $ 重複原來的會話和 $ FIN_C $ MAC 失敗。如果攻擊者將伺服器流量重播到客戶端請求，那麼不同的 $ r_C $ 會阻止 $ ms $ 從再次匹配。
證書驗證
$ Sign_{sk_S} $ 使用伺服器的密鑰 $ sk_S $ 生產 $ \sigma_S $ 簽名，而客戶端可以提取伺服器公鑰 $ pk_S $ 從收到的葉子證書 $ CRT $ 消息，以便客戶端可以驗證 $ \sigma_S $ 簽名。如果這是正確的，客戶端可以確定伺服器確實擁有證書的私鑰。
從另一端，當客戶端必須被認證時 $ Sign_{sk_C} $ 函式使用客戶端證書的私鑰生成 $ \sigma_C $ 簽到 $ CV $ 伺服器使用客戶端收到的客戶端證書的公鑰驗證的消息 $ CRT $ 資訊。
另外：該圖僅對於 TLS 1.0 到 1.2 是正確的（或幾乎是正確的），而不是 1.3。它沒有解釋地提到數字 3.2，它是 TLS 1.1 的內部版本，表明它旨在匹配該版本，用於兩個 DHE 密鑰交換（DHE_RSA 和 DHE_DSS）。但它引用了 CDH，這通常意味著Cofactor Diffie-Hellman，TLS 不使用它 - 在那個步驟中它沒有顯示 $ p,g $ 作為這些協議的參數，它們肯定是。（在 1.3 中它們仍然是，但通過可被視為“源”的預定義曲線。） 1.0 和 1.2 對於大多數握手是相同的，但在（共享）密鑰推導的第二部分略有不同。
- Diffie Hellman 密鑰交換
我相當肯定這部分可以在 SKE 和 CKE 的交換中找到，因為它們包含帶有簽名的公鑰，並且可以被另一方用來導出共享密鑰
基本上，是的。SKE 包含參數 (p,g) 和公鑰，這稱為 Y，但 RFC 稱為 Y_s；CKE 在此處包含公鑰 X，但在 RFC Y_c 中。服務端在 SKE 中也提供簽名，客戶端可以在 CV 中提供簽名（與 CKE 相鄰但不在 CKE 中）；雖然這些有助於整體握手，但它們對 DH 本身沒有貢獻。
- 挑戰/回應
我無法辨識這部分。由於這部分通常是您在交換密鑰之前要做的事情，因此我認為它只能出現在帶有 CH 的部分中。但是，我看不到 CH（挑戰？）對伺服器 S 來說是一個挑戰，因為通常挑戰是通過使用私人資訊來解決的
首先，全大寫和大部分大寫的項目（除了 SID = Session Identifier、PRF 和 CDH）顯然是 TLS 消息類型的縮寫：
CH = Client Hello
SH = Server Hello
SKE = Server Key Exchange
CRT = Certificate
CReq = 證書請求
SHD = 伺服器問候完成
CKE = 客戶端密鑰交換
CV = 證書驗證
CCS = 更改密碼規範
FIN = 完成
參見例如RFC 4346 7.3 第 33 頁的摘要圖。注意伺服器第一次飛行中的Creq，客戶端第二次飛行中的CRT和CV，顯示在括號中，表示它們是可選的；這對應於 RFC 摘要圖中的星號。
TLS 握手有兩個挑戰：客戶端和伺服器隨機數，此處顯示為 $ r_C $ 和 $ r_S $ . 這些包含在已簽名的數據中（始終是伺服器，有時是客戶端，如上所述），（共享）密鑰派生，以及完成的消息值（MAC 握手）。
- 證書驗證
我知道證書由公鑰和數字簽名組成，但是如何在沒有建立共享密鑰的情況下在這裡對證書進行身份驗證？我在這裡也沒有看到任何證書頒發機構，所以我一無所知
應用於 TLS 的證書驗證和確認（經常互換的術語，儘管可以進行區分）包括幾個步驟，我不確定您的老師打算讓您涵蓋哪個步驟。首先，證書（與此處相關的類型）包含公鑰和簽名，還包含許多其他資訊。並且證書本身沒有經過身份驗證，而是用於驗證其他內容 - 在 TLS 中，伺服器幾乎總是通過證書進行身份驗證，而客戶端有時（但很少）是。儘管 TLS 連接幾乎總是使用基於證書的身份驗證，但嚴格來說它不是 TLS協議的一部分：TLS 僅傳送證書數據，將其處理留給依賴端點。TLS可以還以預先生成的 OCSP 響應的形式傳達證書“狀態”（即撤銷）資訊；這稱為“裝訂”，自 2012 年左右開始變得非常普遍，但不在您的圖表中。雖然每個證書都由證書頒發機構頒發，相關的 CRL 和/或 OCSP 資訊由 CA 或代表 CA 頒發，但 CA 不參與 TLS 協議。
有關HTTPS證書鏈使用和驗證的基本解釋，請參閱我對這個 Q 的舊答案。更正式一點：
- 每個證書均由 CA 頒發和簽名；實際上，您的伺服器的證書不是由根 CA 直接簽名的，而是至少有一個中間 CA 介於兩者之間，並且從您的伺服器證書（或使用時客戶端的證書）到根的中間證書的證書列表是稱為鏈
- 通過使用來自鏈中下一個證書或根的公鑰驗證其簽名來驗證鏈中根以下的每個證書；並檢查證書數據中的多項內容，參見RFC5280 第 6 節；並檢查撤銷，有幾個選項，以及到期
- 可以為每個依賴者單獨定義受信任的根 CA 集，儘管通常使用系統提供的或瀏覽器提供的預設值；根 CA 資訊通常儲存為一系列自簽名證書（儘管這不是絕對必要的，請參見 Java
CertPathValidatorAPI）並稱為“信任庫”- 對於某些TLS 應用程序（如 HTTPS），檢查伺服器的“葉”（最終實體）證書中的名稱以確保它辨識正確的伺服器（客戶端想要連接的伺服器）