Mbed-TLS中TLS 1.3握手过程中Client Random变更问题分析

在TLS 1.3协议实现中，当客户端收到服务器的Hello Retry Request后重新发送Client Hello时，Mbed-TLS库存在一个可能导致连接失败的重要问题。本文将深入分析该问题的技术细节、产生原因以及解决方案。

问题现象

在TLS 1.3握手过程中，当服务器发送Hello Retry Request要求客户端重新协商参数时，Mbed-TLS客户端在第二次发送Client Hello消息时会生成一个新的随机数（Client Random），而不是保持第一次Client Hello中的随机数不变。这种行为违反了TLS 1.3协议规范。

通过抓包分析可以观察到：

• 第一次Client Hello中的随机数为：ab2fbef2a704f824008923f44e97eeee143d8abefcff66ed3300ebf5481151d4
• 第二次Client Hello中的随机数变为：5969c4095d5c4e463d73725dff7e53d0012bbe25a8a654bf932c64d8aa489a5a

协议规范要求

根据TLS 1.3协议RFC 8446第4.1.2节明确规定：

• 在Hello Retry Request后发送的Client Hello必须与初始Client Hello相同
• 唯一允许修改的部分是key_share、early_data和cookie扩展
• 客户端随机数（Client Random）必须保持不变

这一设计是为了保证握手过程的安全性和一致性。随机数的改变可能导致某些严格遵循协议的服务器实现（如picotls）拒绝连接。

问题根源

该问题源于Mbed-TLS库在实现TLS 1.3握手流程时的一个缺陷。当处理Hello Retry Request时，代码没有正确保存初始Client Hello中的随机数，而是在重新生成Client Hello时又调用随机数生成函数创建了新的随机值。

影响范围

该问题影响以下配置环境：

• 使用Mbed-TLS 3.5.1及更早版本
• 启用了TLS 1.3协议（通过MBEDTLS_SSL_PROTO_TLS1_3宏定义）
• 与严格遵循TLS 1.3协议规范的服务器交互
• 在握手过程中触发Hello Retry Request场景（如服务器要求不同的密钥交换组）

解决方案

Mbed-TLS开发团队已经在3.6.0版本中修复了这个问题。修复方案主要包括：

1. 在初始Client Hello生成后保存随机数值
2. 在Hello Retry Request后的Client Hello中复用保存的随机数
3. 确保其他必须保持不变的字段也得到正确保留

对于无法立即升级到3.6.0版本的用户，可以考虑以下临时解决方案：

1. 禁用可能导致Hello Retry Request的配置选项
2. 在代码中手动修改随机数生成逻辑
3. 使用兼容性模式（MBEDTLS_SSL_TLS1_3_COMPATIBILITY_MODE）

最佳实践

为避免类似问题，建议开发人员：

1. 定期更新Mbed-TLS到最新稳定版本
2. 在启用新协议版本前充分测试各种握手场景
3. 使用协议分析工具（如Wireshark）验证握手过程符合规范
4. 特别注意协议中关于消息一致性的特殊要求

该问题的修复体现了Mbed-TLS项目对协议规范严格遵守的承诺，也提醒我们在实现加密协议时需要特别关注各种边界条件和特殊流程。