Browsed by
Tag: dtls

ICE 与 DTLS-SRTP

ICE 与 DTLS-SRTP

IP 通信领域 —— 无论是 WebRTC 还是 SIP 通信 —— 处理媒体流时有两个需要仔细考虑的问题:(1)连通性,以及(2)安全。前者通过 ICE(Interactive Connectivity Establishment,交互式连通性确立)解决,后者通过SRTP、DTLS-SRTP 解决。

SIP 通信网络中 SIP 服务器往往具备转发流的功能,或者在网络中部署媒体网关,因此 ICE 并不是一个必选项,呼叫建立后双方(或者终端与服务器之间)进行 DTLS 握手协商、建立 SRTP 加密媒体流通道,双方通话。

而在 WebRTC 网络(或者 WebRTC – SIP 混合网络)中,可能仅仅部署 STUN 服务器,未必会部署 TURN 服务器,因此必须通过 ICE 确保媒体通道的连通性。旧版 WebRTC 只要求 SRTP 传输媒体,ICE 连通性确认后双方即可通话,而新版 WebRTC 要求必须采用 DTLS-SRTP 传输媒体,因此双方建立信令连接后,必须要确认媒体通道连通性、DTLS 握手协商后才能进入通话,如下图所示:

WebRTC 媒体通道建立过程
WebRTC 媒体通道建立过程

ICE 协商(即 STUN request + response)在 DTLS 握手协商之前。这点很好理解,如果没有完成 ICE 连通性确认,双方的媒体节点未必真实可达(一方或者双方位于私网后的情况非常普遍),DTLS 消息可能无法到达对方,从而无法完成 DTLS 握手协商。

建立 SRTP 连接后,WebRTC 节点之间依然会定时进行 ICE 协商确保双方媒体流的连通性,整个会话过程中 STUN request、response 消息不需要采用 DTLS 加密,STUN 消息自己的 username、password 以及 identify 等参数可以确保交互的安全。

DTLS-SRTP

DTLS-SRTP

DTLS-SRTP 开发工作主要基于两点考虑:(1)后续和 webRTC 对接时,无论是 Chrome 还是 Firefox,都要求采用 DTLS-SRTP 传输媒体;(2)在企业通信领域,如果用户不部署「SIP over TLS」, SRTP 加密用的 key 和 salt 在 SIP 消息中明文传输,有可能被有心人士拦截,从而破解 SRTP 流。

与 webRTC 对接还有很多繁琐的细节需要处理,以后再另外讨论。

对于企业通信中可能存在的拦截破解问题,目前通用的解决方法就是部署 DTLS-SRTP。DTLS-SRTP 不再通过 SIP 会话消息传递 key 和 salt,而是在 SRTP 建立之时双方 RTP 端点先进行 DTLS 协商,双方交换证书和密钥,进而加密、解密出 key 和 salt。具体步骤如下图所示:

DTLS-SRTP 流程
DTLS-SRTP 流程

SIP 消息中有两处需要注意:

(1)fingerprint 参数,指示了各自证书的 fingerprint。双方在 DTLS 协商时以此验证证书的有效性。篡改 fingerprint 或者拦截证书,都会导致 DTLS 协商失败。

(2)setup 参数,指示 RTP 端点在 DTLS 协商过程中的角色。DTLS 协商明确要求一方是 client(即协商的发起方),另一方是 server,具体细节请参考 RFC5763

在 DTLS 协商过程中随机生成 key 和 salt,完成协商后 RTP 端点从结果中提取出双方的 key 和 salt,对 RTP 流加密和解密,也就是后续 SRTP 流的处理。