WebRTC-RS项目中SRTP扩展处理不当导致密钥长度不匹配问题分析

问题背景

在WebRTC-RS项目中，开发者在使用该库实现与OpenAI实时API的WebRTC连接时，遇到了一个关键性的错误。当建立DTLS连接并尝试启动SRTP会话时，程序发生了panic，错误信息显示在密钥派生过程中出现了32字节与16字节的长度不匹配问题。

问题现象

错误发生在webrtc-srtp库的密钥派生模块中，具体表现为尝试将一个32字节的密钥切片强制转换为16字节的AES-128密钥数组时触发了断言失败。从日志中可以清晰地看到，虽然协商的加密套件是TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256（使用AES-128），但SRTP会话却试图使用32字节的密钥。

技术分析

深入分析后发现，问题的根源在于SRTP保护配置(Protection Profile)的选择机制上：

1. DTLS握手过程：在DTLS握手阶段，服务器端通过use_srtp扩展提供了可用的SRTP保护配置列表，顺序为：

   • SRTP_AEAD_AES_256_GCM
   • SRTP_AEAD_AES_128_GCM
   • SRTP_AES128_CM_HMAC_SHA1_80

2. 配置选择机制：客户端在选择SRTP保护配置时，简单地选择了列表中的第一个匹配项（AES-256 GCM），而没有考虑与主加密套件的兼容性。

3. 密钥派生冲突：虽然主加密套件使用的是AES-128（需要16字节密钥），但SRTP会话却按照AES-256（需要32字节密钥）的要求进行密钥派生，导致了长度不匹配的错误。

解决方案

这个问题有两种解决方式：

1. 临时解决方案：通过设置引擎强制指定优先使用的SRTP保护配置，确保与主加密套件一致：

   let mut setting_engine = SettingEngine::default();
   setting_engine.set_srtp_protection_profiles(vec![
       SrtpProtectionProfile::Srtp_Aead_Aes_128_Gcm,
       SrtpProtectionProfile::Srtp_Aes128_Cm_Hmac_Sha1_80,
   ]);
   

2. 官方修复：项目维护者在后续版本(v0.13.0)中修复了这个问题，改进了SRTP保护配置的选择逻辑，确保与主加密套件的兼容性。

技术启示

这个案例揭示了WebRTC实现中几个重要的技术点：

1. 分层安全机制：WebRTC同时使用了DTLS和SRTP两套安全机制，它们虽然独立工作但需要保持参数一致性。

2. 扩展协商机制：use_srtp扩展允许两端协商SRTP参数，但实现时需要谨慎处理与主加密套件的关系。

3. 密钥派生过程：SRTP密钥派生依赖于主加密套件生成的密钥材料，派生过程必须考虑主加密套件的密钥长度限制。

对于WebRTC开发者而言，理解这些安全机制间的交互关系至关重要，特别是在实现自定义或非标准WebRTC应用时。项目维护者最终修复了这个问题，但开发者仍需注意类似的安全参数匹配问题。