uTLS项目中TLS 1.3握手签名验证问题深度解析

在uTLS项目使用过程中，开发者发现访问特定域名时会出现tls: invalid signature by the server certificate: crypto/rsa: verification error错误。这个问题特别有趣，因为它只在TLS 1.3握手时出现，而在TLS 1.2握手时却能正常工作。

问题现象与初步分析

当使用uTLS库访问某些特定网站时，如果客户端尝试建立TLS 1.3连接，握手过程会在证书验证阶段失败。通过深入测试发现：

1. 使用标准库的TLS实现可以正常连接
2. 使用uTLS的TLS 1.2配置也能成功握手
3. 问题仅出现在尝试TLS 1.3握手的场景

这种选择性失败表明问题很可能出在uTLS对TLS 1.3特定握手流程的实现上。

根本原因探究

经过对握手流程的详细追踪，发现问题源于uTLS处理握手消息时的转录(transcript)管理机制。在TLS 1.3中，握手消息的完整性验证依赖于对完整握手过程的哈希计算。

关键发现点在于：

1. 服务器发送的CertificateRequest消息包含了一个compress_certificate扩展
2. uTLS的解析函数会忽略它不认识的扩展
3. 这导致重构握手消息时与原始消息不一致
4. 最终导致签名验证时哈希值不匹配

解决方案设计

针对这个问题，社区提出了两种解决方案思路：

1. 直接修复方案：显式处理compress_certificate扩展，确保它能被正确解析和重构

2. 更通用的解决方案：为所有握手消息类型添加原始字节存储字段，就像clientHelloMsg已经做的那样。这样可以确保：

   • 原始握手消息被完整保存
   • 转录哈希计算使用原始字节而非重构后的数据
   • 避免因扩展处理差异导致的验证失败

技术细节深入

TLS 1.3的证书验证机制相比TLS 1.2有重大变化：

1. 使用握手转录哈希作为签名基础
2. 所有握手消息必须严格保持原始字节序列
3. 任何重构过程中的差异都会导致验证失败

uTLS当前实现中，certificateRequestMsgTLS13等消息类型在解析时会丢弃未知扩展，这破坏了原始消息的完整性。相比之下，标准库直接使用原始字节进行哈希计算，避免了这个问题。

最佳实践建议

对于遇到类似问题的开发者，建议：

1. 在关键业务场景中，优先使用经过充分测试的TLS 1.2配置
2. 如果需要使用TLS 1.3，考虑实现原始字节存储方案
3. 对握手过程进行详细日志记录，便于问题诊断
4. 关注uTLS项目的更新，及时获取官方修复

这个问题很好地展示了TLS实现中的微妙之处，即使是看似无害的消息解析差异，也可能导致协议级别的验证失败。理解这些底层机制对于开发可靠的加密通信应用至关重要。