SRT协议v1.5.3版本在Rendezvous模式下GCM加密的接收端崩溃问题分析

问题背景

在SRT（Secure Reliable Transport）协议v1.5.3版本中，当使用Rendezvous连接模式并启用GCM（Galois/Counter Mode）加密时，接收端会出现段错误（Segmentation fault）导致程序崩溃。这个问题在后续的v1.5.4版本中得到了修复，但在v1.5.3版本中仍然存在，影响了版本间的兼容性。

问题重现与验证

通过实际测试可以重现该问题，以下是几种测试场景：

1. 问题场景1：发送端和接收端都使用v1.5.3版本，在Rendezvous模式下启用GCM加密（cryptomode=2），接收端会出现段错误。

2. 问题场景2：发送端使用v1.5.4版本，接收端使用v1.5.3版本，同样会出现接收端崩溃的情况。

3. 正常场景：当发送端和接收端都升级到v1.5.4版本时，连接可以正常建立，数据传输稳定。

技术分析

根据提交记录，该问题在v1.5.3a版本中通过commit cf7eb33得到了修复。修复的核心内容是增加了对m_GroupOf指针是否为NULL的检查。这表明原始问题可能源于：

1. 空指针访问：在加密握手过程中，代码尝试访问一个未初始化的或已释放的组指针（m_GroupOf）。

2. 竞态条件：在多线程环境下，可能在加密上下文尚未完全建立时就尝试访问相关资源。

3. 版本兼容性问题：v1.5.3和v1.5.4在加密握手协议上可能存在细微差异，导致旧版本无法正确处理新版本发来的加密参数。

影响范围

该问题主要影响以下使用场景：

• 使用SRT v1.5.3版本
• 采用Rendezvous连接模式
• 启用了GCM加密（cryptomode=2）
• 存在不同版本间的互操作性需求

解决方案

对于遇到此问题的用户，建议采取以下措施：

1. 升级版本：将SRT升级到v1.5.3a或更高版本，这是最直接的解决方案。

2. 临时规避：如果无法立即升级，可以考虑：

   • 使用其他加密模式（如AES-CBC）
   • 改用其他连接模式（如caller/listener模式）

3. 代码级修复：对于需要自行维护代码的用户，可以参考v1.5.3a的修复方式，在访问m_GroupOf前增加NULL检查。

最佳实践建议

1. 版本一致性：在生产环境中，尽量保持发送端和接收端使用相同版本的SRT实现。

2. 加密模式选择：根据实际安全需求选择合适的加密模式，GCM虽然提供了认证加密，但在某些旧版本中可能存在兼容性问题。

3. 测试验证：在部署前，应对不同版本组合进行充分的兼容性测试，特别是加密相关的功能。

4. 监控日志：在运行过程中密切监控错误日志，及时发现和处理类似的段错误问题。

总结

SRT协议v1.5.3版本在特定配置下存在的接收端崩溃问题，反映了加密实现和版本兼容性方面需要特别注意。通过版本升级或配置调整可以有效解决该问题。这也提醒开发者在实现安全协议时需要特别注意边界条件和异常处理，确保代码的健壮性。