Rustls项目中Unbuffered API处理大证书时的解密错误问题分析

问题背景

在Rustls项目中使用Unbuffered API时，当服务器端使用大尺寸证书且TLS消息被分割成多个数据包传输时，客户端可能会报告DecryptError错误。这个问题主要出现在0.23.13和0.23.14版本中，经过调查发现可能与deframer或TLS消息处理逻辑的回归问题有关。

问题现象

当出现以下情况时，问题会被触发：

1. 服务器使用需要多个TLS消息传输的大尺寸证书
2. 一个或多个TLS消息被分割成多个网络数据包传输
3. 前一个TLS消息已被解密但未被丢弃
4. 当前TLS消息不完整

当完整消息到达后，process_more_input()会从意外的解密内容开始处理，导致解密错误。

技术分析

问题重现

通过修改测试用例可以重现此问题，关键修改是在服务器配置中设置较小的max_fragment_size值（如1024字节），强制服务器将大证书分割成多个TLS消息：

let mut server_config = make_server_config_with_versions(KeyType::Rsa2048, &[version]);
server_config.max_fragment_size = Some(1024);

问题根源

通过日志分析发现，当deframer迭代器(DeframerIter)中同时包含完整消息和不完整消息时会出现问题：

1. 迭代器缓冲区中同时存在一个完整消息和一个不完整消息
2. 第一个完整消息被正确解密
3. 第二个消息随后完整到达
4. 但迭代器仍然指向第一个消息的位置，导致后续处理从错误的位置开始

详细流程

从日志中可以观察到以下关键点：

1. 初始接收到的TLS消息被正确解析：

   0x1000 bytes opaque message: [16, 3, 3, 0, bb, ...]
   

2. 后续消息被分割传输：

   0xf40 bytes opaque message: [14, 3, 3, 0, 1, ...]
   

3. 问题出现时的关键状态：

   0x4ee5 bytes opaque message: [17, 3, 3, 40, 11, ... , 17, 3, 3, 40, 11, ...]
   

   这里缓冲区包含一个完整消息和一个不完整消息

4. 第一个消息被解密：

   plain message: [b, 0, c8, 25, 0, 0, c8, 21, ...]
   

5. 问题显现：第二个消息完整到达后，迭代器仍指向第一个消息：

   0x5ee5 bytes opaque message: [17, 3, 3, 40, 11, b, 0, c8, 25, ...]
   

解决方案建议

1. Deframer迭代器改进：确保在处理完一个完整消息后，迭代器能正确前进到下一个消息位置，即使后续消息不完整。

2. 缓冲区管理优化：在消息解密后应立即从缓冲区中移除已处理的部分，防止后续处理从错误位置开始。

3. 状态一致性检查：在处理消息边界时增加额外的验证，确保不会在消息中间错误地开始解析。

总结

这个问题揭示了Rustls项目中Unbuffered API在处理大证书和分割消息时的边界条件问题。通过改进deframer迭代器的行为和缓冲区管理策略，可以解决这类解密错误。对于使用Unbuffered API的开发人员，建议在服务器配置中适当设置max_fragment_size参数，并关注后续版本中对此问题的修复。