今天讲一下WebRTC的安全性理解，一是因为陆续从事通讯和安全领域，二是基于这两年大火的Zoom所暴漏的一系列安全问题。

在WebRTC领域Google已经有了相对完整地考虑，不过大家都知道WebRTC只有媒体处理部分的技术，信令部分都是开发者/厂家自己实现的，而信令部分也是Zoom暴露安全问题比较多的部分。

下面从数据传输安全，拒绝服务攻击，隐私保护几个方面描述对WebRTC安全性的理解
下面两个是WebRTC的最简单的P2P通话

和视频会议的媒体交互架构



对于网络传输的安全，由于在IP网上传输，如果没有加密，则会出现黑客在云端/局域网中数据截取，从而获取到信令协商数据和会议语音/视频内容的问题。对于WebRTC的媒体处理上，已经使用了DTLS-SRTP技术，使用DTLS类似SSL证书方式来协商加解密秘钥，使用SRTP实现对于媒体(音频视频)数据加密和完整性保护，实现媒体传输的安全保护；同样，对于信令协商，也需要采取TLS/DTLS进行信令数据传输的保护，当然这取决于各厂家的具体实现方式(如HTTPS，SIPS)，但是是不是信令层面使用了传输层加密就已经解决了安全性问题呢，当然不是，由于使用的信令协议本身的安全性/漏洞问题，会发生拒绝服务攻击，数据窃取攻击，这点在下面的安全威胁中描述。

拒绝服务攻击

针对信令服务器，可以看到信令通讯都是对互联网开放的，因此此业务暴露开放的端口(包括TCP端口，HTTP API接口)，因此也是最容易受到攻击的，此类型的攻击基本是传统的DOS/DDOS攻击(比如TCP半链接攻击，HTTP Flood攻击)，目的就是破坏性的让信令服务器无法提供服务；另外针对单用户的攻击，像信令协议自身的缺陷，SIP这种通用的RTC协商信令协议，有很多的方法可以使攻击者将合法用户禁用掉，包括：进行针对用户设备的DOS暴力破解攻击，攻击者快速频繁且反复地发送注册请求 ；伪造报文将用户去注册；伪造结束报文非法结束用户的通话。这都是WebRTC信令服务的潜在危险。

针对媒体服务器/媒体终端，由于媒体地址和媒体端口都是通过SDP协商的，SDP消息如果被恶意篡改(比如127.0.0.1)，则会导致媒体处理者的媒体报文自我循环，从而造成媒体处理方无法提供服务。

隐私保护问题

一般提到的都是终端权限使用问题和端到端加密问题

一是摄像头，麦克，文件的使用问题，是否可以随意获取用户摄像头和麦克风的使用权限，WebRTC通过要求用户必须明确地对摄像头和麦克风的使用进行授权来解决此问题。

二是一个终端使用SRTP加密后，发到媒体服务器处理，通过媒体服务器处理后发往另一个终端，可以看到终端<->媒体服务器之间的路径是加密的，但由于媒体服务器解密后进行处理，则存在了媒体明文暴露点，也就存在了安全风险。

除了上述两点之外，在会议录制以及合法使用者的非法问题

在视频会议体系中，一般都提供会议录制/录音服务，方便用户后续回顾使用，此服务分两种方式，1是服务器端侧录制，2是媒体终端侧录制；对于服务器端录制，访问会议录制视频，也是使用URL的方式，如果没有校验性的密码保护或者存在弱密码安全威胁，如果使用暴力破解方式，也同样会出现非法获取到会议录制视频；对于终端录制，也存在入会后的合法用户进行本地录制，合法用户也可能会将这些视频发布到互联网上，造成敏感数据泄露。这些安全问题已经得到了不同程度的解决，像录制权限只有会议主讲人控制是否开启，对于合法用户的非法泄密尤其要关注，这类安全问题通过会控是无法解决的，需要考虑引入数字水印技术进行震慑以及出现后的追溯，但是既然存在这个功能，就会存在数据泄露/内部泄密的问题。
虽然现在有不少的安全威胁和问题，但是随着RTC的发展和大家对安全越来越重视，相信RTC的安全会越来越更好的发展