WebRTC如何保证数据安全
WebRTC 在数据传输过程中对数据安全性的要求是极为严格的。WebRTC 是如何保障数据的安全性的呢？图 7.3 展示的就是 WebRTC 保障数据在网络上安全传输的机制。
使用 WebRTC 实现对音视频通信产品进行防护有三个级别，分别是应用级防护、信令级防护以及数据级防护。
-
应用级防护。如图 7.3 中的步骤❶，用户在使用音视频通信产品时，一般都要先进行注册，然后通过用户名/密码的方式登录到应用系统上。这一级防护称为应用级防护，但这一级防护并不属于 WebRTC 的范畴。
-
信令级防护。当用户通过第一级防护后，就可以获得 WebRTC 信令服务器的地址，并通过信令服务器进行媒体协商。媒体协商成功后，通信双方便可以从彼此的 SDP 中获取对方的用户名/密码，即 ice-ufrag 和 ice-pwd 信息。这两个信息的作用是验证用户的合法性，其完整过程如下：通信的双方彼此发送 STUN Binding 请求（带着 ice-ufrag 和 ice-pwd）给对方，当对方收到请求后，会验证请求中的 ice-ufrag 和 ice-pwd 是否与自己 SDP 中的一致，如果一致，则说明该用户是合法的用户，否则说明它是非法用户。这就是图 7.3 中的步骤❷和步骤❸。
-
媒体数据加密，如图 7.3 中的步骤❹和步骤❺。对于非法用户，即使突破第二级防护得到了媒体数据，也无法将这些数据还原成音视频，因为这些数据都是加密过的。WebRTC 是如何进行数据加密的呢？当第二级防护通过之后，通信的双方还会使用 DTLS 协议彼此交换证书，证书中保存的最重要的信息就是公钥。例如 ClientA 向 ClientB 发送媒体数据，ClientA 需要用 ClientB 的公钥对数据加密，加密后的数据再打包成 SRTP 发送给 ClientB，接收端（ClientB）需要使用自己的私钥才能将加密的数据解密。
在上述三级防护中，第二级和第三级防护都属于 WebRTC 的防护范畴。清楚了 WebRTC 的整体运行机制之后，来看一下 SDP 中哪些信息是与 WebRTC 安全机制相关的，如代码 7.8 所示。
...
m=...
...
a=ice-ufrag:kSq+
a=ice-pwd:MRW8liIi4S8OCRlM+SftfJWF
...
a=fingerprint:sha-256 DB:43:34:45:52:D3:78:A3:92:6E:BB:FB:83:2E:7F:22:49:5B:A7:73:D4:E1:52:1C:67:7F:7F:EA:95:F1:05:50
a=setup:actpass
...在 WebRTC 的 SDP 中，不同类型的媒体都有对应的安全信息，但这些信息的内容都是一样的，因此在使用时只要保留一份即可。
首先看一下代码 7.8 中的第 4∼5 行，ice-ufrag 表示 username（用户名），ice-pwd 表示 password（密码）。WebRTC 终端相互通信时，需要使用这两个值进行用户有效性验证。
接下来看一下代码中的第 8 行代码，该行用于决定使用 DTLS 协议时通信双方的 “角色”。“a=setup” 属性可以设置多种角色，分别为 active、passive 以及 actpass。其中active 表示终端的角色为客户端；passive 表示终端的角色为服务端；actpass（active 与 passive 组合而成）表示终端既可以是客户端又可以是服务端，最终的角色由另一端的角色确定。一般情况下，第一个加入房间的终端默认为 actpass，后来加入的终端为 active。因此，通过 “a=setup” 的属性值，可以知道使用 DTLS 协议时通信双方哪个是客户端，哪个是服务端。
第 7 行代码中的 “a=fingerprint” 属性用于验证加密证书的有效性。当通信双方通过 DTLS 协议交换证书时，如何才能保障证书在网络上交换的过程中没有被篡改呢？这就要用到 “a=fingerprint” 属性了。通过 DTLS 协议交换证书之前，各端会先给各自的证书生成一个指纹（fingerprint），然后将指纹放到 SDP 中通过信令交换给对方。通过 DTLS 协议交换证书后，双方会对拿到的证书重新生成指纹。然后将生成的指纹与 SDP 中的指纹进行比较，如果两者一致，则说明证书在传输中没有被篡改，可以放心使用，否则说明证书被篡改，此时连接创建失败。
以上就是 SDP 中与安全相关属性的作用，这些属性应用于 WebRTC 安全的不同阶段。ice-ufrag 和 ice-pwd 用于验证 WebRTC 客户端是否有效，fingerprint 用于验证证书的有效性，而 setup 用于指明 WebRTC 终端使用 DTLS 协议交换证书时的角色。