TLS 1.3 C#客户端实现：握手消息解密失败及数据长度异常

关于ServerHello后大尺寸Application Data的说明 #

TLS 1.3允许服务器将EncryptedExtensions、Certificate、CertificateVerify、Finished等多个握手消息打包进同一个加密记录发送，因此4569字节的长度未必是异常，核心问题在于该记录的解密逻辑是否正确，以及keylog文件无法解密的根源——这大概率和握手哈希计算、密钥推导错误有关。

Keylog文件解密失败的排查要点 #

• 确认keylog格式严格符合标准：每行必须是CLIENT_RANDOM <ClientHello随机数> <对应密钥>，且要包含握手阶段的流量密钥（TLS 1.3中握手密钥与应用层密钥是独立派生的，不要漏录）。
• 检查Wireshark的TLS版本识别：确保Wireshark正确解析为TLS 1.3，版本协商错误会直接导致解密失败。

代码模块的关键检查项 #

1. 握手哈希计算 #

• 握手哈希是所有已发送/接收的握手消息原始字节的串联（不含TLS记录层头部），解密ServerHello后的第一个加密记录时，哈希输入应为ClientHello字节 + ServerHello字节。
• 哈希算法必须与ServerHello中hash_algorithm字段指定的一致（如SHA256、SHA384），不能硬编码固定算法。

2. 共享密钥生成 #

• 若使用ECDH密钥交换：确认曲线参数（如secp256r1）匹配服务器要求，公钥采用未压缩格式，共享密钥计算符合ECDH规范（避免私钥/公钥编码错误）。
• 若使用PSK：确保PSK绑定的哈希值与ClientHello中的psk_binder计算逻辑一致。

3. 握手密钥推导（严格遵循RFC 8446 HKDF流程） #

• 密钥派生步骤不能出错：

  early_secret = HKDF-Extract(0, client_psk/0)
  handshake_secret = HKDF-Extract(early_secret, derived_secret)
  server_handshake_traffic_secret = HKDF-Expand-Label(handshake_secret, "server handshake traffic", "", key_length)
  client_handshake_traffic_secret = HKDF-Expand-Label(handshake_secret, "client handshake traffic", "", key_length)
  

• 注意HKDF-Expand-Label的info参数必须严格匹配：比如"server handshake traffic"的大小写、空格都不能有误，密钥长度要对应所选AEAD算法（AES-GCM是16字节，ChaCha20-Poly1305是32字节）。

4. 解密逻辑（AEAD算法实现） #

• IV生成必须符合规范：以ChaCha20-Poly1305为例，IV由HKDF-Expand-Label(traffic_secret, "iv", "", 12)派生的固定值，拼接无符号64位大端序列号（从0开始递增）。
• AEAD附加数据必须包含完整的TLS记录头字段：记录类型（1字节） + TLS版本（2字节） + 加密后数据长度（2字节），不能遗漏或传错。
• 解密后需按握手消息的长度字段拆分多个消息，确保每个消息的完整性。

建议你贴出以下关键代码片段以便进一步定位：

• 握手哈希计算的核心代码
• HKDF密钥推导的实现
• AEAD解密的调用逻辑

内容的提问来源于stack exchange，提问作者PiotrKowalski