媒体加密与通信安全
有各种不同的做法会让实时通信软件暴露在安全隐患中。其中需要特别值得注意的是在信息传输的过程中截取未加密的媒体或者数据。这可以发生在浏览器到浏览器之间或者浏览器到服务器之间的通信过程中，第三方可以窃取到所有发送的数据。但是在数据加密之后，可以有效的组织窃听者获取通信流中的内容。只有拥有加密密钥的会话参与方才可以将通信数据流解码。
加密功能在WebRTC中是强制要求的，所有内容，包括信令机制，都必须进行加密工作。所以，所有通过WebRTC发送出的媒体流都会通过标准化的知名的加密协议得到保护。由传输通道的类型决定加密协议；数据流使用数据报传输层安全协议（DTLS）进行加密，媒体流使用安全实时传输协议（SRTP）进行加密。
4.3.1 DTLS：数据报传输层安全协议
WebRTC使用DTLS加密发送的信息，所有通过RTCDataChannel全都使用DTLS来确保安全性。
DTLS是一个标准化的协议，已经内置在了所有支持WebRTC的浏览器中，并且始终在网页浏览器，电子邮件和VoIP平台上进行信息加密工作。该协议内置的特性意味着不需要再使用前进行任何设置。与其他加密协议一样，DTLS的目标是防止信息窃取。DTLS是基于面向流的TLS所建模的，TLS是一个使用非对称密码技术，数据和信息授权技术来提供全面加密技术的协议。TLS是实际的网页加密标准，TLS被设计用来给可靠的TCP传输机制提供服务，但不适用于使用UDP这种不可靠传输机制的VoIP应用。
DTLS协议是从SSL衍生来的，所有数据都认为是与使用任何基于标准SSL连接中的数据一样安全。事实上，WebRTC数据可以通过任何基于标准SSL的连接来进行保护，使WebRTC可以在几乎任何服务器场景中提供端到端加密。
参考文献[8]
4.3.1.1 TURN上的DTLS
所有WebRTC通信的默认选项是在两个浏览器之间建立直接P2P通信，在设置阶段有信令服务器的帮助。在TURN通信过程中，媒体可能会出现质量降低以及延时增加的情况，但是允许“如果其他所有都失败了”这种情景迫使WebRTC应用在很差的环境下继续工作。我们必须考虑在TURN的替代通信结构上进行通信加密。
我们知道，无论什么通信方法，被发送的数据都会在终端被加密。TURN服务器的目的是简单的在通话参与方之间进行WebRTC数据传输，以及只在获取路由目的的时候对WebRTC数据包中的UDP层进行解析。服务器不会为了路由数据包而解码应用数据层信息，所以我们可以确定它们不会（且不能）对DTLS加密产生影响。
所以，加密保护不会因为WebRTC通信在TURN上传输就受损，并且服务器不能读懂或者更改对等端之间所传送的信息。
4.3.2 SRTP：安全实时传输协议
基本的RTP不具备任何内置的安全机制，而这就导致了传输的数据没有任何保护。取而代之的是使用外在机制来给数据提供加密。事实上，使用未经加密的RTP是被WebRTC规范所明文禁止的。
WebRTC使用SRTP来对媒体流进行加密，而不是DTLS。这是因为SRTP相比于DTLS，是更轻型的协议。规范要求任何WebRTC实现都要支持RTP/SAVPF。但是，实际的SRTP密钥交换最开始时使用DTLS-SRTP进行的，可以检测到任一MiTM攻击。
4.3.3 安全连接的建立
在这一小节中让我们来探讨一下WebRTC应用建立一通新的通话的过程。在这个例子中，有两个会话参与方，Alice和Bob。在一方（Alice）打电话给另一方（Bob）的时候初始化通话进程，然后信令处理在双方之间交换相关的数据元。
一旦初始ICE检查结束了，双方就会开始设立一个或多个安全通道。最开始，DTLS握手会发生在ICE所创立的所有通道上。对于这些数据通道而言，单独这一步作为简单的DTLS对于加密来说已经足够用了。但是对于媒体通道，需要进行其他的额外步骤。
一旦DTLS握手结束后，密钥被“发出”并且作为媒体通道的密钥SRTP。在这一步，会话双方都知道他们可以使用这些密钥与对方分享安全的数据和/或媒体通道，并且这些通道是不为恶意的第三方所知晓的。
参考文献[10]
4.3.4 DTLS-SRTP vs SDES
为了在媒体传输会话中协商安全性参数，SRTP需要与密钥管理协议进行互动。此协议是未确定的，给任务提供多个可能的选择。其中两个选择分别为SDES和DTLS-SRTP。
需要提醒的是，多媒体通信中涉及到的信令（SIP，HTTP）和媒体（RTP）可以单独地进行安全加密。
SDES
对媒体流的SDP安全描述（SDP Security Description for Media Streams, SDES）是WebRTC之前所选择的方法。
SDES中，被用来设立SRTP会话的安全性参数和密钥，以SDP属性的形式进行交换。因为SDP是在信令平面上进行传输的，如果不是额外再针对信令消息进行加密的话，那么窃听者还是可以获得密钥，从而窃取SDES加密的数据。换句话说，还需要再使用一个额外的加密协议来给信令平面进行加密。一种实现方法是使用TLS。
但是，如果单独对信令和媒体进行加密，可能会使媒体用户与信令用户不同的情况发生（不保证一定会发生）。为了能够保证上述事情发生，还需要有密码捆绑。DTLS-SRTP就是可以提供这项保证的机制之一，但是SDES不能。
至今还存在一个尚未解决的问题，就是大部分VoIP网络的RTP数据并没有安全保护。事实上，为了将花费削减到预算可接受程度，用户通常都会先向技术提供商提出砍掉加密功能的要求。当得到安全保证后，绝大多数使用SDES的部署，就像我们刚刚提到的那样，很大程度上的依赖于信令平面的安全性。
DTLS-SRTP
另一方面，DTLS-SRTP在媒体平面上交换密钥，而不是信令平面。这项不同之处使SRTP媒体通道不需要像SDES一样，在SDP信息交换中不需要将私钥暴露出来。
WebRTC规范指出WebRTC实现必须支持DTLS-SRTP来进行密钥管理。还有，DTLS-SRTP是默认方案，而且不允许使用其他的密钥管理方案。换句话说，其他的方案可能，也可能不会得到一点支持。
如果一个请求或者“通话”被同时支持DTLS-SRTP和SDES的对等端接收，无论信令加密与否，都必须选择使用DTLS-SRTP。
https://webrtc.org.cn/webrtc-security/