Kamailio项目中WSS连接的TLS信息获取问题分析

在Kamailio SIP服务器项目中，当处理WebSocket Secure(WSS)连接时，系统无法正确获取TLS版本和加密套件信息的技术问题。本文将深入分析该问题的技术背景、产生原因以及解决方案。

问题现象

在Kamailio处理WSS连接时，通过伪变量$tls_version和$tls_cipher_info获取TLS相关信息时返回<null>值。日志中可见如下关键错误信息：

Transport protocol is not TLS (bug in config)
TLS connection not found in select_version
TLS connection not found in select_cipher

技术背景

Kamailio作为高性能SIP服务器，支持多种传输协议：

1. 传统TLS协议(PROTO_TLS)
2. WebSocket Secure协议(PROTO_WSS)

虽然WSS本质上是在WebSocket协议基础上添加TLS加密层，但在Kamailio的代码实现中，这两种协议被区分为不同的协议类型。

问题根源

问题出在tls_select.c文件中的get_cur_connection()函数实现。该函数仅检查PROTO_TLS协议类型，而忽略了PROTO_WSS协议类型：

if(msg->rcv.proto != PROTO_TLS) {
    ERR("Transport protocol is not TLS (bug in config)\n");
    return 0;
}

这种严格的协议类型检查导致WSS连接无法通过验证，进而无法获取TLS相关信息。

解决方案

Kamailio开发团队已提交修复代码，主要修改包括：

1. 修改协议检查逻辑，同时接受PROTO_TLS和PROTO_WSS协议类型
2. 更新相关错误处理和信息日志
3. 确保TLS信息获取函数能正确处理两种协议类型

技术影响

该修复对于以下场景尤为重要：

• 使用WSS协议的WebRTC应用
• 基于浏览器的SIP客户端
• 需要详细TLS信息的安全审计场景

最佳实践建议

对于需要处理混合协议(TLS/WSS)的环境，建议：

1. 定期更新Kamailio版本以获取最新修复
2. 在配置文件中明确区分不同协议的处理逻辑
3. 对关键安全信息(如TLS版本)进行有效性验证

总结

此问题展示了协议栈实现中类型检查的重要性。在多层协议(如WSS over TLS)场景下，开发人员需要特别注意底层安全信息的透传问题。Kamailio通过完善协议类型检查机制，确保了TLS信息在不同加密传输层中的一致性获取。