如何辨識 TLS 會話中使用的 ECDHE 組值
在 ECDHE 中，團體是一種公共價值。我想為會話獲取此值。我使用 Wireshark 檢查了會話。在ServerHello -> Key share extension -> Key share entry下，我找到了這些參數：
Key Share Entry: Group: x25519, Key Exchange length: 32 Group: x25519 (29) Key Exchange Length: 32 Key Exchange: 22d9....88e....635... (full length is 64 hex character, 256 bit)你能解釋更多嗎？那麼密鑰交換長度值怎麼可能是 32，但它是 256 位和 64 十六進製字元？
TLS 1.3 握手的工作原理如下：
客戶端將向伺服器發送一個“ClientHello”資料結構。在這個階段，客戶端還不知道伺服器支持哪些“組”。為了避免到伺服器的額外往返，它可以推測性地包含它更喜歡使用的組的“組元素”。在所詢問的情況下，組元素是一個 32 字節的公鑰，用於“組 29”（29 == hex 0x1d），它是通常稱為 X25519 的 TLS 標識符。所有 TLS 支持的組的編號列表如下：https ://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
X25519 表示使用 Curve25519 橢圓曲線上眾所周知的基點 G 進行的 Diffie-Hellman 交換，其中群元素位於該曲線內包含 G 的大循環子群中。不必傳輸 G 點，因為它被定義為X25519 標準的一部分，並且對於 X25519 的所有呼叫都是相同的。
客戶端的臨時公鑰是推測發送的“組元素”。對於 X25519，它是 32 字節長（64 個十六進製字元，或 256 位）。該組元素在 ClientHello 資料結構的“密鑰共享”部分中列為“密鑰交換”值。
如果伺服器同意使用客戶端的推測性包含的組，這裡是組 29，則伺服器將響應“ServerHello”消息。這包括“密鑰共享”部分的“密鑰交換”值中的伺服器組元素。該組元素是伺服器的臨時公鑰。
有了這些資訊，客戶端和伺服器都可以計算出相同的共享密鑰，稱為“預主密鑰”。然後將其與 ClientHello 和 ServerHello 數據組合以派生對稱加密密鑰（請參閱https://datatracker.ietf.org/doc/html/rfc8446#section-7.1）。這些允許伺服器和客戶端使用經過身份驗證的加密（如 AES-GCM）安全地相互通信。
如果伺服器不同意客戶端建議的組，或者客戶端選擇不建議任何組，但伺服器確實同意客戶端在“支持的組”中列出的（其他）組，它會發送 HelloRetryRequest 告訴客戶端使用指定的組重試 ClientHello，然後伺服器如上所述接受該組。如果伺服器不同意客戶端支持的任何組，它會發送錯誤警報並且握手失敗——除非客戶端也提出了可用的 PSK，但通常只發生在恢復時，如果初始握手失敗恢復是不可能。
TLS 1.0-1.2 以不同方式處理 ECDHE——如果有的話，因為它是可選的。在這些協議中，密碼套件為 HMAC（如果不是 AEAD）和 PRF（如果 1.2）指定密鑰交換和身份驗證以及數據密碼和散列。客戶端發送 ClientHello 列出它支持的密碼套件，其中任何、部分或全部可以結合 RSA 或 ECDSA 身份驗證（即證書）使用 ECDHE，以及支持組擴展（或 RFC7919 之前的支持曲線）指定它支持的曲線。如果伺服器同意提供的 ECDHE 密碼套件和提供的曲線，它會發送指定密碼套件的 ServerHello，然後是其證書鏈，然後是包含曲線 ID 及其臨時公鑰的 ServerKeyExchange。客戶端（如果它接受證書）發送包含其臨時公鑰的 ClientKeyExchange，之後共享密鑰計算類似地進行，儘管工作密鑰的派生方式與 1.3 不同，也與 1.2 和更早版本不同。