了解 TLS 連接調試輸出中的簽名和雜湊算法
我有一個使用 TLSv1.2 進行通信的應用程序。我使用選項
-Djavax.net.debug=allCipher Suites: [TLS_DHE_DSS_WITH_AES_128_CBC_SHA] Compression Methods: { 0 } Extension signature_algorithms, signature_algorithms: SHA512withECDSA,SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA, MD5withRSA Extension renegotiation_info, renegotiated_connection: <empty> *** [read] MD5 and SHA1 hashes: len = 74我不太明白這個輸出。
- 客戶端發送它想要使用的密碼套件，並且簽名算法擴展對應於該密碼套件？
- 我也不明白
[read] MD5 and SHA1 hashes: len = 74為什麼消息的長度等於 74 ？
雖然你沒有這麼說，但這似乎是一個伺服器端日誌；您的“應用程序”正在接受來自客戶端的其他連接。
是的，客戶端發送它支持並願意在 ClientHello 中使用的密碼套件列表；這通常不止一個（通常是 10 到 20，有時超過 50），但它可以是一個，如您的範例中所示。但是，僅提供使用 DHE-DSS 的套件需要伺服器具有 DSS（又名 DSA）證書，這在公共 Internet 上很少見，儘管它在 Intranet 中可能更常見（尤其是在美國政府中）。請參閱rfc 5246 第 7.4.1.2 節，與早期版本相比，這方面的內容沒有實質性變化。每個使用證書身份驗證（不是匿名或純 PSK、SRP、Kerberos）的密碼套件都定義了伺服器 (EE) 證書中的公鑰類型，因此定義了“原始”簽名算法（不簽名的普通 RSA 除外） all) 但不是相關的雜湊。
僅在 TLS1.2 中，客戶端可以包含 signature_algorithms 擴展，指示它支持驗證的簽名類型。如果使用，這將限制伺服器在 ServerKeyExchange 上完成的簽名（如果是短暫的（和 DHE-DSS 是）），以及伺服器鏈中證書上的簽名（根/錨除外，如果存在，因為驗證它是無意義的）。如果在 TLS1.2 中未使用，則伺服器採用密碼套件隱含的簽名類型，以及 SHA1；請參閱第 7.1.4.1 節。此外，如果使用，以前限制第二種(CA) 證書密鑰類型的稀有靜態(EC)DH 密碼套件不再這樣做；請參閱第 7.4.2 節。
早期版本的 TLS 沒有簽名算法；ServerKX 上的伺服器簽名始終使用 SHA1+MD5 用於 RSA 和 SHA1 用於 DSA 和 ECDSA 的非標準組合，並且證書籤名沒有特別限制，但在 2015 年之前，實際上幾乎總是使用 SHA1 或 MD5。MD5 現在被認為是證書籤名損壞，幾乎所有依賴者（瀏覽器和客戶端）都禁止使用 MD5。直到 2009 年，DSA 的標準 FIPS 186 甚至都不允許它使用除 SHA1 之外的任何散列，並且在此之後大多數實現都需要一段時間才能效仿。
為了完整起見，如果在 TLS 1.2 中使用客戶端身份驗證，則 CertVerify 中的客戶端簽名（如果是短暫的）和證書籤名受 CertificateRequest 中的類似欄位 supported_signature_algorithms（必需，不是擴展）以及所選證書（和密鑰）的約束這受 certificate_types 欄位的約束；請參閱第 7.4.4 節。在早期版本中，只有 certificate_types 存在，CertVerify 簽名使用像 ServerKX 這樣的預設雜湊，而實際上證書籤名使用 SHA1 或 MD5。
所有版本的 TLS（回到 1.0）還允許客戶端發送一個 supported_curves 擴展來標識它支持哪些橢圓曲線。如果存在和ECDH
$$ E $$密碼套件經過協商（僅當客戶端提供它/它們時才會發生）伺服器必須在該列表的曲線上使用 ECDH 密鑰（點）；如果存在並且協商了 ECDHE-ECDSA 密鑰交換，它必須使用證書（並因此簽署 ServerKX）該列表中曲線上的密鑰；如果存在並且使用了任何 ECDSA 簽名的證書，則它們必須使用該列表中的曲線。在實踐中，supported_curves 列表通常是兩條以前的 NSA-SuiteB 曲線，P256 和 P384，有時擴展為添加 P521。 你不高興你問:-？