Apache TrafficServer 10.1.x版本SSL_read_early_data崩溃问题分析

问题背景

在Apache TrafficServer 10.1.x版本的生产环境测试中，开发人员发现了一个频繁发生的崩溃问题。该问题出现在SSL握手过程中，具体是在处理早期数据(early data)时发生的。崩溃堆栈显示问题发生在OpenSSL库的ssl3_ctrl函数中，而触发点则是TrafficServer代码中对SSL_get_negotiated_group的调用。

崩溃现象分析

从崩溃堆栈可以看出，问题发生在SSL握手阶段，具体是在服务器端处理早期数据的过程中。崩溃时的关键调用链如下：

1. SSLNetVConnection::sslServerHandShakeEvent调用了_ssl_accept
2. 进而调用OpenSSL的SSL_read_early_data函数
3. 最终在ssl3_ctrl函数中发生崩溃

特别值得注意的是，当代码尝试获取协商的SSL/TLS组参数时（通过SSL_get_negotiated_group函数），系统发生了崩溃。这表明在SSL握手尚未完全完成的状态下，某些SSL上下文信息可能还未完全初始化。

根本原因

经过测试验证，发现问题与TrafficServer的#11844变更直接相关。该变更在ssl_callback_info函数中添加了对SSL_get_negotiated_group的调用。进一步简化测试表明，仅仅添加这一行代码就足以重现崩溃问题。

这表明在SSL握手过程的特定阶段（特别是处理早期数据时），SSL上下文的状态可能还不适合查询协商的组参数。OpenSSL库在这种情况下可能无法正确处理这个查询请求，导致程序崩溃。

解决方案

开发团队通过以下步骤解决了这个问题：

1. 首先确认了问题与#11844变更的直接关联性
2. 通过简化测试复现了最小崩溃场景
3. 最终决定回滚相关变更以解决崩溃问题

这个案例提醒我们，在SSL/TLS握手过程中，特别是在处理早期数据这样的高级特性时，需要特别注意API调用的时机和上下文状态。某些SSL函数只能在握手完全完成后才能安全调用。

经验总结

对于类似网络服务器开发，特别是涉及SSL/TLS高级特性的场景，开发者应当：

1. 充分理解SSL握手过程的不同阶段
2. 谨慎处理早期数据等高级特性
3. 对SSL上下文状态敏感的API调用要特别注意调用时机
4. 生产环境部署前应进行充分的边界条件测试

这个问题也展示了开源协作的优势，通过社区成员的快速反馈和验证，能够迅速定位和解决复杂的底层网络问题。