翻译：刘通
摘要
网页实时通信技术（简称WebRTC）是目前网页应用技术的一大发展趋势，WebRTC承诺不需要安装任何形式的插件或者程序就可以让浏览器获得进行实时通信的能力。但是，其开源的特点可能会造成潜在的安全隐患。此篇论文将要细节地对WebRTC的安全性展开讨论。
1 引言
WebRTC是一项开源的基于网页的应用技术，其允许用户在不安装任何插件的情况下就可以发送实时媒体流。使用适当的浏览器就可以简单地通过相关网页给另一方拨打网络电话。
下面列举了一下WebRTC的主要应用方向：
# 实时音视频通话
# 网络会议
# 直接数据传输
与大多数实时系统（比如SIP）不同，WebRTC通信是直接由某些网页服务器通过JavaScript API进行控制的。
不靠插件直接使用浏览器进行音视频通信的前景是令人兴奋的。但是，人们很自然的就会对这种技术的安全性产生忧虑，想知道其是否可以得到我们的信任，来在终端用户和任何中间商或者第三方之间提供可靠的通信服务。
本文将会涉及到上述问题，并且测试WebRTC是否会在各种场景中提供安全的服务。但是出于本文的目的，原生应用程序并不在本文的考虑范围内。
2 WebRTC架构概览
WebRTC可以在两个对等端之间建立直接的媒体通信，使用的是端到端（P2P）拓扑结构。WebRTC内置于用户的浏览器中，不需要下载额外的软件就能运行。实际的端间通信是通过交换元数据作为开始的，这里的元数据叫做“信令”。这个过程被用来开启和广播对话，并且帮助不相识的双方之间的连接建立。
如图1所示，上述过程由一个中间服务器来实现：
图1 一则WebRTC简单通话的拓扑结构
信令机制并不是WebRTC规范中所规定的，于是就允许开发者自己选择协议。这就使WebRTC应用可以适应不同的用户案例和不同的场景。
WebRTC通信是如何工作的？
WebRTC依赖3个API工作，每一个都有指定的功能，互相协同工作才能在网页应用中实现实时通信。本文将对这些API进行简单的介绍和分析。每个协议和技术的具体实现方法和技术细节并不在本文的讨论范围，但是读者可以在网上查找到相关的文章进行阅读。
# getUserMedia
多年以来，想要实现电脑端的音视频捕捉，都需要依靠第三方浏览器插件来实现，比如Flash或Silverlight。但是在HTML 5的时代，可以直接接入众多硬件设备，并且提供JavaScript API可以与系统的基础硬件功能相连接。
getUserMedia是上面提到这些API之一，功能是给浏览器获取用户摄像头和麦克风的权限。虽然是WebRTC使用的API，但是getUserMedia实际上是HTML 5的一部分。
# RTCPeerConnection
RTCPeerConnection是WebRTC规范中特有的两个API之一。一个RTCPeerConnection接口代表实际的WebRTC连接，负责处理两对等端之间的高效数据流。
当一个通话者想与远方通话者建立一个对话连接，浏览器通过具体使用一个RTCPeerConnection对象来开启对话。其中包括一个与其对等端相交换的自生SDP描述。接收者用它自己的SDP描述作为响应。SDP描述被用来做为ICE工作流的一部分，用来实现NAT穿越。
现在有了建立起来的连接，RTCPeerConnection开始在浏览器之间，实时地发送音视频数据作为比特流。
最终，RTCPeerConnection API还要负责管理每个端到端连接的生命周期，还负责将所有连接的设定，管理和单个易用接口的陈述都封装在一起。
RTCPeerConnection有两个特性：— 两个浏览器之间直接进行通信 — 使用UDP/IP — USP不能保证数据包能够被接收端接收（TCP/IP不同，可以保证数据传达），但是这一点可以大大地减少网络负荷。（通过丢失部分数据，我们就可以专注于提供实时通信服务）。
# RTCDataChannel
RTCDataChannel是WebRTC提供的第二个主要API，并且代表主要的通信通道，用来交换对等端之间的数据。换句话说，RTCDataChannel的任务是来从对话的一端到另一端进行直接的数据传输。
尽管有其他可替代的通信通道可以选择（比如WebSocket，Server Sent Events），但是这些通道都是在中间用一个服务器来实现通信的，而不是像RTCDataChannel一样可以实现对等端之间的直接相连。RTCDataChannel与著名的WebSocket很相像，但不同的是RTCDataChannel在提供用户定制的传输特性时，使用的是端到端制式。
2.1 基本技术
上述三个主要API是WebRTC面向开发者的方面，但是也有很多基础的技术来提供这些协议（RTCPeerConnection和RTCDataChannel API）。
我们需要ICE，STUN，TURN来实现建立和维持UDP端到端连接。DTLS用来确保两端之间数据传输的安全。最后，SCTP和SRTP是用来复用不同数据流的应用协议，提供拥塞和流量控制，以及提供部分可靠的传输和其他的UDP服务。
SDP：会话描述协议（Session Description Protocol）
会话描述协议（SDP）作为一个描述性协议，被用作声明和管理会话邀请的标准方法，并且负责多媒体会话的邀请任务。SDP以文字格式描述了浏览器的性能及表现，包括以下信息：— 媒体性能（视频，音频）和使用的codecs — IP地址和端口号 — P2P数据传输协议（WebRTC使用SecureRTP） — 通信可用的带宽 — 会话属性（名称，ID，活跃时间等等） —> 但是这些WebRTC并没有使用 — 其他相关的元数据……
现如今，SDP在会话初始化协议（SIP），实时传输协议（RTP），以及实时流协议（RSP）中都得到广泛使用。
参考文献[3]
ICE：交互式连接建立（Interactive Connectivity Establishment）
信令需要首次使用中间服务器来交换元数据，但是一旦完成之后，WebRTC尝试在用户之间建立一条直接的P2P连接。这项处理工作由ICE框架负责。
ICE是一个用来在对等端之间建立连接的框架。尽管WebRTC想要使用直接的P2P连接，但实际上由于广泛存在的NAT（网络地址转换），使这项工作变得很困难。
由于现在所使用的IPv4机制的长度只有32位，绝大多数网络设备都没有一个可以在互联网上直接可见的唯一公共IPv4地址。NAT在传出请求通过它的时候，动态地转换私有地址到公共地址。相似的，传入请求的时候讲公共IP地址转换回私有IP，确保在内网上可以进行正确的路由。因此，共享私有IP地址通常是不足以提供足够的信息来建立一个通往对等端的连接。ICE尝试克服由NAT产生的困难，来找到一条连接对等端的最佳道路。
通过尝试各种可能，ICE可以选择一个最高效的方法来工作。ICE首先尝试使用从设备操作系统和网卡观察到的主机地址来创建连接；如果失败的话（对于处在NAT之后的设备来说是必然发生的事情），ICE会使用STURN服务器获得一个外部地址。如果这次尝试也失败的话，数据流会通过一个TURN中继服务器传回重新进行路由。
候选通信路由以基于文字的形式呈现，并且以优先级为顺序进行排列。会选择以下几点中的一种形式：— 直接P2P通信 — 使用STUN，用一个端口映射NAT穿透（这条路由最终会产生直接的P2P通信） — 使用TURN作为中间媒介。
如果所有可能候选项都不满足，会选择一条负荷最小的路线作为路由。
参考文献[4]
STUN：会话对NAT的穿越能力
为了进行P2P通信，会话参与双方都需要至少知道其对等端的IP地址和指定的UDP端口。作为结果，在WebRTC通信建立之前，需要进行一定数量的信息交换。
每个对等端需要使用一个STUN服务器来决定他们的公共IP地址，这个IP在连接建立的时候回呗ICE框架所引用。STUN服务器是典型的公开可接入性，并且可以由WebRTC应用自由使用。
TURN
最终如果P2P通信建立失败的话，一个后退选项会通过TURN服务器提供。通过在对等端之间传输数据流，WebRTC通信可以得到确定，但是会造成媒体质量的下降和延迟。
TURN服务器无论在何种终端用户的环境中，都可以确保建立通话的高成功率。因为数据中间会被送入一个中间服务器，所以服务器带宽也会被占用。如果同时有很多通话被路由到了服务器处，那么就需要有很大的带宽才能满足。
服务器本身来说并不是刻意随意连入的，需要由应用提供者来进行特定的供应。
3 基于浏览器的安全性考虑
无论是在中间传输阶段还是在终端用户处，实时通信应用都有出现安全问题的可能性。这些安全隐患存在于任何处理实时数据及媒体传输的应用软件中。
WebRTC与其他的RTC app所不一样的是，它可以给软件开发的新手提供稳定可靠的架构而不对其安全性造成损伤。我们现在要一一讨论WebRTC是如何处理这些安全隐患的。
参考文献[5]
3.1 浏览器信任模型
WebRTC架构将网络资源按照安全性进行分级。从用户角度来看，浏览器（或者用户客户）是WebRTC所有安全性的基础，并且作为他们的可信计算基础（Trusted Computing Base, TCB）。
浏览器的任务是在给用户提供适当的安全保护的前提下连入互联网。WebRTC的安全要求是直接按照上述要求所建立的；浏览器是用户可以访问WebRTC所有应用和内容的门户。
尽管服务器所提供的HTML和JS会让浏览器执行一系列的指令，但浏览器将这些脚本指令隔离在沙箱中。也就是沙箱将脚本与脚本相隔离开，以及将它们与用户电脑所隔离。总的来说只能与来自同一域名的资源进行交互—或者更准确的说，只能与同一来源的资源进行交互。
浏览器强制执行用户所需要的所有安全性准则，并且作为第三方验证的第一部。所有授权的实体都有其自己被浏览器所验证的标识。
如果用户选用了他们可信任的合适的浏览器，那么所有WebRTC通信都可以被视为是“安全的”，并且遵循WebRTC技术所接受的安全性的架构标准。但是，如果对所用浏览器的“可信度”有任何质疑的话（比如从第三方所下载的，而不是从授信网站处），那么所有接下来的与WebRTC应用进行的交互都会受到影响，而且可能不会确保百分之百的安全传输。
换句话说，WebRTC提供给用户的信用等级会直接影响用户对浏览器的信任度。
3.2 SOP：同源策略（Same Origin Policy）
不管是部分还是全部页面在加载的时候，网页资源会被网页的网络服务器所捕捉到，这是DOM的一个基础方面。捕捉资源有可能在页面第一次被加载的时候发生，也有可能当网页中的脚本发出对应请求的时候发生。这些脚本可以通过例如XMLHttpRequest() API产生HTTP请求，但是不允许发送请求改变任何他们指定的服务器。确切的说，请求必须由脚本相同的“起始点”所产生。“起始点”由URI方案，主机名，和端口号组成。上述限制被称为同源策略（SOP）。
SOP强使脚本在指定到他们初始域名的沙箱中隔离运行，这样就可以防止来源于不同起点或者防止由交换信息造成的同页面的iframe。同起始点服务器的网页和脚本依旧保持了与其他JS变量的唔阻碍交互性。同样的，起始点构成了网络沙箱的基本单元。
通过在每个起始点基础上实施执行沙箱，终端用户就可以避免滥用他们的授权信息。你可以期待安全地使用社交网络，而避免出发藏在广告下的脚本，并且窃取你的登录信息。
同样的，服务器，也就是网页提供方，也会受到保护防止从用户浏览器来的攻击；如果这个保镖不存在的话，DoS攻击就会通过滥用的资源请求而出现。
参考文献[6]
3.2.1 分流SOP
尽管SOP存在一些缺点，会使一些特定种类的网页应用更难构建，但是对于用户和网络服务器来说，SOP是非常非常重要的。允许网页内部交互的机制是存在的，虽然会同时赞成和限制特定的通道。
W3C的CORS规范是解决上述问题的解决办法之一。它允许浏览器联系脚本的目标服务器来决定它是否愿意加入特定种类的交换中。同样的，跨源请求可以通过继续目标服务器选项来特定地选择加入一个请求并且拒绝其他请求，以达到被安全授予的目的。
WebSocket是另一个可以提供类似功能的选择之一，但是是在透明通道上而不是被隔离的HTTP请求。一旦这个连接被建立了，脚本就可以传输数据流和资源了。
上述两种情况中，初始验证阶段都会阻止脚本与不同起始点进行随机数据传输。
4 WebRTC安全性考虑
参考文献[7]
4.1 安装与更新
传统电脑版软件中的一个普遍问题是可否对应用本身产生信用。一个新软件或者插件的安装，常常会在不知情的情况下被安装了恶意软件或者本身并不想安装的垃圾软件。很多终端用户并不知道这些软件是怎么来的，也不知道他们是从哪里下载的。恶意的第三方特别擅长用安全且授信的软件来包装自己的恶意软件，并且在免费的软件网站上提供他们的用户包。
但是WebRTC不需要安装任何形式的插件和其他内容。所有基本的WebRTC技术都已经作为浏览器的一部分被内置其中，典型的具有WebRTC功能的浏览器例如Chrome和Firefox。如果用户使用的是这种浏览器，他们可以在不进行提前设置或者准备的情况下就随时浏览或者使用任意一个WebRTC应用。所以只要使用的是合适的WebRTC应用，就不用担心会不小心安装什么恶意软件或者病毒了。
另外一个相关的考虑是给已经发现的软件漏洞打补丁。就像任何一项软件技术一样，WebRTC在未来的使用过程中也一定会发现bug和易受攻击漏洞。如果发现了一个传统电脑软件中的易受攻击漏洞，开发针对此漏洞的补丁可能会花费掉一定的时间。这是应用开发中的一个常见问题，安全是仅次于功能以外最棘手的问题。更加深入的分析，我们可以考虑硬件基础的通信方法。通常VoIP电话多久会进行一次安全性更新呢？你会信任负责进行日常更新的人吗？甚至说，你知道是什么人负责进行日常更新吗？
与此相反的是，浏览器由于用户上报问题的高频率和大范围，以及其本身存在的特性，浏览器一直处于一个高速开发状态中。因为WebRTC的内容是作为浏览器的一部分所提供的，它很可能经常会在浏览器升级的同时获得升级。一旦发现了一个WebRTC浏览器实现中的易受攻击漏洞，那么很有可能会立即对其开展修复工作。实际情况我们也可以从Chrome和Firefox紧密的开发周期中验证上述说法。事实上，在自动更新周期中，WebRTC内容可以一旦补丁在服务器上可用的同时，就通过新版本的浏览器得到更新。现在绝大多数的浏览器都有着在发现严重安全漏洞的24小时自动更新的良好记录。
还需注意的是：尽管我们说了WebRTC不需要安装插件，第三方WebRTC框架有可能会需要使用插件来在还未支持WebRTC的浏览器（比如Safari和IE）中才能工作。在这种情况下，建议弹出一个警示窗对用户进行提示。
4.2 接入媒体/本地资源
浏览器可以接入本地资源（包括摄像头，麦克，文件），然而也就不可避免的引发对网页激活用户麦克风和摄像头的思考。如果网页应用可以随意获取用户摄像头和麦克风的使用权限，那么不良的软件可能就会在用户不知情的情况下打开摄像头和麦克风进行录像录音。这是滥用用户信任的一个简单例子（用户甚至可能都没有注意到）。
WebRTC通过简单的手段来阻止上述危险发生，就是要求用户必须明确地对摄像头和麦克风（两者都可以单独进行）的使用进行授权。可以询问用户是仅本次同意，还是永久性同意。WebRTC应用不可能随意获取权限或者操作任意一个设备。另外，当麦克风或者摄像头正在被使用的时候，用户UI需要明确地显示出麦克风或者摄像头正在工作。在Chrome中，在使用用户媒体设备的标签页上会有明确地标识。
这项安全保护的理念是用户每次都需要自己进行决定是否允许拨打通话或者接听通话。换句话说，用户必须明白：— 谁或者什么正在请求获取我媒体设备的权限？— 媒体流是传输到哪？— 或者二者都需明白。
作为一项额外的规定，WebRTC标准规定了浏览器应该在UI被覆盖（也就是此窗口被其他窗口覆盖）的时候，停止使用摄像头和麦克风。尽管这是一个理想的情况，但是这点并没有必要保证。幸运的是，这像额外的功能很有可能并不是用户想要得到的。
屏幕分享带来了对安全性更深的思考。用户可能不会立即意识到他们所共享的范围到底有多大。事实上，他们常常会认为他们只是在与他人共享一个特定的窗口，但是他们其实是在给其他人共享整个屏幕。上述过程是用户错误的设定屏幕共享设置而造成的，或者也有可能是用户在使用中忘了他们分享的范围是什么了。
4.3 媒体加密与通信安全
有各种不同的做法会让实时通信软件暴露在安全隐患中。其中需要特别值得注意的是在信息传输的过程中截取未加密的媒体或者数据。这可以发生在浏览器到浏览器之间或者浏览器到服务器之间的通信过程中，第三方可以窃取到所有发送的数据。但是在数据加密之后，可以有效的组织窃听者获取通信流中的内容。只有拥有加密密钥的会话参与方才可以将通信数据流解码。
加密功能在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。
讨论
大家已经广泛接受了DTLS-SRTP是作为WebRTC媒体加密的强制选项。但是大家有异议的是，其他机制，例如SDES，是否应该也被使用来提供向后兼容性呢。
考虑到兼容性问题，Google Chrome浏览器对SDES和DTLS-SRTP都提供支持。Mozilla的Firefox浏览器只实施DTLS-SRTP机制。
参考文献[11][12]
4.3.5 SRTP的缺点
SRTP只对RTP数据包的负载内容进行加密，不会对报头提供任何加密保护。但是，报头包含了很多可能需要保持私密性的信息。
其中包含于RTP报头中的信息是所承载媒体数据的音频等级（audio-level）。有了音频等级这项参数，看到SRTP数据包的任何人都可以知道任意一个时刻哪些用户在说话，哪些没有。尽管媒体本身内容还是保持隐秘，不会被任何窃听者获得，但是报头的暴露还是一个很可怕的隐患。举个例子，执法人员就可以通过获得到的这些数据判断出，这个用户是不是正在和已知的坏人正在进行通话。
4.4 基于网络的对等端验证以及身份管理
我们希望用户能够识别他们对等端的身份信息，也就是用户很自然的想要确认他们正在沟通的人就是他们想要进行交流的那个人，而不是某个冒名顶替的骗子。
尽管信令服务器可以为用户身份声明起到某些方面的作用，但信令服务器本身却不是被信任的。我们需要将对等端验证的工作与信令服务器相独立出来。这可以通过使用身份提供者来实现。
最近有很多基于网络的身份提供者（IdP）在网上变得很常见，包括Facebook Connect，BrowerID（Mozilla提供），OAuth（Twitter提供）。这些机制的目的很简单，就是以身份验证提供者本身的权力在其他服务器/用户那里对你的身份信息进行验证。如果有一个用户有一个Facebook账户，那么他就能使用Facebook Connect来向其他用户证明，他就是他在Facebook上声称自己是的那个人。这使用户可以将他们在其他服务上的验证信息，与他们已授信服务上的主要账户相捆绑。注意这种情况中，身份提供者所掌控的“信任”等级对终端用户或者服务来说是主观的，并且通常是与用户在互联网上的声誉所紧紧捆绑的。
因为是由不同的公司独立进行开发的，所以每个IdP的实现之间都会不同，但是基础的方法和功能都是基本一样的。IdP不会给信令服务器提供身份验证；但是，他们会给用户（以及他们的浏览器）提供验证。WebRTC也不会要求使用哪项服务，而这是基于网页应用的实现使用的。
因为网页应用（通话发起端）与验证过程无关，浏览器能够安全的产生验证处理过程的输入内容，以及安全地在网页应用上显示输出内容，是很重要的一点。这个过程决不能被应用进行篡改和误传。
4.5 IP位置隐私性
使用ICE的一个不好的地方是一个对等端可以获取到另一方的IP地址。由于IP地址是全球公共注册的，他们就可以根据IP地址获取例如对等端所处位置的细节信息。当然这对对等端用户来说是不利的，所以他们想要避免这件事情的发生。
WebRTC最初的设计目的并不是用于防止用户的信息被不良网站所窃取。通常，这些恶意网站会从任何HTTP事务中获得用户的信息，至少会得到用户服务器的反射地址。想要将IP地址隐藏起来对服务器不可见的话，需要有其他特定的机制，在本文中不会进行论述。
WebRTC具有很多机制，可以使网页应用于用户一起将用户的IP地址隐藏起来，对会话的另一方不可见。接下来将要对这些机制进行详细的描述。
WebRTC实现要求提供一项机制，让JS抑制着ICE协商，直到用户决定接听来电为止。这项规定协助终端用户在拒绝接听通话的时候阻止对方获取自己的IP地址。
第二个这种规定是任何实现都必须提供一个机制，发起通话的app的JavaScript需要知名只用TURN候选项才能被使用。这可以防止对方获取用户的IP地址。
另外，还有一个机制要求通话发起方软件要重新配置现有通话来加入一个非TURN候选项。与上文所写的两个机制一同，使ICE协商能够在拨入通话提示的时候立即建立起来，这样可以降低延时，也会避免在用户决定接听以前就公开用户的IP地址。这就令用户可以在通话的过程中完全隐藏自己的IP地址。
参考文献[13]
4.6 信令层
由于信令协议并没包括在WebRTC规范中，加密机制很明显的依赖所选的信令协议。因为信令安全性的相对开放属性，本文将要专注于对SIP进行简单的解释。
SIP是VoIP通信中广泛使用的标准，来设立和结束通话。但是，SIP是由HTTP和SMTP所衍生来的—这两个协议都是规范开发的。因为它使用明文消息进行信息交换，所以就很容易被不怀好意的人窃取SIP消息。如果攻击者能够看到用户的敏感信息，他们就可以用这些信息来敲诈用户。并且如果攻击者能够获取连入操作网络的权限，他甚至都有可能破解出WebRTC通信中的核心内容。[14]
因为SIP是通过纯文本发送的，对于攻击者要想窃取到SIP消息真的是唾手可得。接下来就有可能窃取到消息所携带的信息，或者消息的报头。如果攻击者窃取到了邀请消息，他们就有可能把报头的源地址改为他们自己的IP地址。
参考文献[10][15]
4.6.1 SIP缺陷
SIP是一项针对信令和控制多媒体通信会话的通信协议，经常应用于VoIP技术，用来建立和结束通话。同样也可以应用于WebRTC实现中的信令目的。但是SIP消息通常是以未经加密的纯文本类型发送的。会引起各种潜在的攻击危险，我们会针对这一方面进行进一步的测试。
SIP流
在建立通话的过程中，用户浏览器使用中心注册表进行注册。传统VoIP必需这个注册过程来定位和连接远端参与方。
当一端（Bob）想要建立一则通话的时候，他通过中央代理服务器（信令服务器）发送邀请消息。服务器负责传输这类消息，以及提供定位另一端用户的方法。服务器想要在查询过程中尝试一系列的方法（例如DNS）来定位终端用户。
注册劫持
最初的浏览器注册是用于声明用户在连接中的地点，并且表明用户的设备是否接受通话请求。但是，这个过程会给不良的人进行“注册劫持”的攻击机会。
在注册消息的交换中包括了“接触：”一项，其中有用户的IP地址。不管什么时候信令服务器处理一则拨入通话，用户名称（或者电话号码）都与注册的IP地址相匹配，并且根据此IP将邀请消息进行传递。这些注册信息是定期更新的，确保现存的记录时刻保持是最新的。
因为SIP消息总是由明文发送的，攻击者很轻易的就能截取并督导这些注册消息中的内容。在窃取到SIP消息之后，可以使用合适的工具（比如SiVuS消息生成器）来声称一个类似的SIP信息，但是在这个假消息中，用户真正的IP地址被替代为攻击者自身的IP地址。攻击者之后只要将实际的用户屏蔽掉，然后周期地发送这类信息，就可以把所有拨入的通话转到他们自己那里。
有很多的方法可以使攻击者将合法用户禁用掉，包括：— 进行针对用户设备的DOS攻击 — 将用户去注册（另一种攻击方法，在本文不会提到）— 开启一场注册竞争，攻击者快速（每15秒）且反复地发送注册请求，这样就会覆盖掉合法用户的注册请求。这都是WebRTC信令服务的潜在危险。
因为SIP的实现不支持对消息内容完整性的检查，所以更改和重放类型的攻击不会被探测到。即便是服务器要求对用户注册进行验证的话也会遭到攻击，因为攻击者一旦捕获了消息的话，就可以任意对消息进行更改和回放了。
这类攻击可以使用SIPS（SIP over TLS）以及验证SIP请求和回复消息来进行抑制。事实上，使用SIPS和回复认证可以抑制很多包括窃听和假扮用户在内的攻击。
其他可能的攻击
# MiTM攻击：
如果攻击者能够窃取到最初的SIP消息，他就可能会进行MiTM攻击。
# 重放攻击：
不法方可以将捕捉到的数据包重放给服务器，造成服务器给原本的目的地拨打电话。换句话说，这会采取第二个来路不明的通话请求，而这个请求与对等端已经接收到的请求完全一样。虽然这是一件很烦人的事情，但是攻击者并不会成为通话的一方，因为他们的IP信息没有包含在信令数据包中。
# 会话劫持：
网页服务器并没有每个独立会话请求的状态。虽然说有验证的Cookies，但是这也只不过是一个有着会话ID的数据文件。这些cookies通过最初的连入权限由网页服务器发送给浏览器。
# 如果cookie被窃取到了并且被复制，它可能会让窃取者获得正在进行会话的完整权限。为了尝试避免此种危险发生，大多数的网站都会使用涉及到用户IP地址和时间戳的算法来生成cookie来产生一个唯一的身份ID。
加密
尽管信令看起来可以提供一些很诱人的有点，但是它会成为攻击者的攻击对象。另外对于媒体流来说，信令层也可以被加密。其中一个加密方法是OnSIP，使用Secure WebSocket上的SIP（wss://而不是ws://），使用由TLS加密的WebSocket连接。
尽管这不在本文的范畴之内，但是还要简单的写一写，其他信令技术与其类似，可以通过使用TLS来对其WebSocket或者其他网络传输进行加密。与所有加密过程相同，只要第三方不知道加密的密钥，他们就无法读懂通信所传输的内容。这会有助于抵挡上文所述的攻击危险，但是需要强调的是，应用程序员必须明确地实现被加密的信令方法，这个功能才有用。
参考文献[16]
4.7 额外的安全性话题
电信网络的脚本
通过给WebRTC提供支持，一个电信网络不应该被暴露在安全隐患中。但是，用户手中的设备和软件会不可避免的可能受到不法人员的攻击。
因此，所有从未信任源（也就是消费者/用户）接收的数据必须要经过验证，电信网络必须认为任何发送给用户的数据都有可能被心怀恶意的人窃取。
为了达到这两点，电信供应商必须努力尝试所有可能性，来保护消费者不会因为他们自身的错误而暴露自己的系统。
跨站脚本（XSS）
跨站脚本（Cross-site scripting）是网页应用中一个典型的易受攻击点。它可以使攻击者侵入网页的客户端脚本。跨站脚本的弱点可能被攻击者利用，来绕开像来源规则一样的连入控制。
跨站脚本的影响可能微不足道，也有可能造成严重的安全隐患，要看网站所处理数据的敏感度以及网站所有者是否用了任何能够抑制安全性的东西。
因为访问WebRTC应用的主要方法是使用可运行HTML5的浏览器，所以有一些特定的安全性考虑比如；保护密钥和敏感信息免受跨站脚本或挂域名的攻击，WebSocket的使用，iframe的安全性，以及其他问题。因为客户端软件是由用户自己所控制的，绝大多数情况不由浏览器所控，所以WebRTC的用户需要尽可能的在安全受保护的环境下使用软件。如果不是的话，用户所发送的所有数据都会暴露。
参考文献[17]
5. 与类似技术的比较
如果不将WebRTC与同类技术的安全性做比较的话，那么只是谈WebRTC的安全考虑就没有什么意义。对于WebRTC来讲幸运的是，在基于网页的通信领域中，都有一些共有的问题。
本段将要展示WebRTC与其他提供RTC功能的平台对比之后得到的结果，也就是WebRTC的优势以及劣势。
我们可以进行探索的平台在下面已经列出。但是将要进行测试的平台还没有选出。（会在以后给出）
尽管被广泛的依赖，但是额外的安装过程也会产生干扰。
# Flash
# Silverlight
# Jabber
# SIP
6. 安全设计实践
WebRTC在设计之初的目标之一就是确保安全。但是除了盲目地依赖于基础技术，最好还是要在编写代码的过程中有意识的注重安全性。本段将要讨论实际编程中可以做什么来得到比普通的WebRTC实现所能提供的更好的安全保证。实际上，这些实践适用于想要处理敏感信息的租住，比如银行，医疗组织，或者公司机密信息。
安全的信令
正如上文提到的，WebRTC并没有在信令处理过程中强加什么限制，而是将这个操作空间留给开发者自己决定他们所倾向的方法。尽管这可以给开发人员提供很大的自由度和灵活性，来适应自己的应用需求，但是这也会带来与特定信令协议相关的安全风险。
使用可以提供额外安全性的信令协议是一件明智的事情，比如对信令数据进行加密。默认上，信令处理不会包含任何加密过程，会使进行交换的信令消息暴露在窃听者眼前。注重安全性/机密性的应用应该确保他们的信令层是基于安全协议所实现的，安全协议有SIPS、OpenSIP、HTTPS或者WSS。
认证及横向监督
一个基本的WebRTC应用只需要用户ID就可以进行一则通话，不需要服务自身角度而言的任何权限认证。人们可能期望在任意用户加入通话之前都需要提前注册或者进行认证。未认证的实体都应该不能够连入会话，并且限制不信任参与方的权限。
因为媒体链接是P2P的，媒体内容（音频和视频通道）在对等端之间进行全双工的直接传输。因此，因为信令服务器可以保持通信之中的对等端数量，它可以持续的监视通话中可疑的人。如果信令服务器中显示的会话参与人数多于在WebRTC网页进行交互的会话参与人数的话，就意味着存在秘密的窃听者，应该通过会话权限来强制将其踢出。
权限请求
通常用户都会在没有阅读消息的情况下就下意识地同意权限请求或者相似的请求对话框。这就有可能同意某些用户实际上并不想要的请求。
尽管这种用户的行为不能简单地处理好，但是有一个解决方法，就是明确地在页面上提示应用正在请求获取什么权限。这种应用应该把用户的隐私放在第一位。
中间人
心存恶意的人有可能成功建立一个MiTM攻击，而且通常没有一个简单的方法来发现并且对抗这种攻击。这是因为MiTM攻击没有任何警示，而且通信还会想正常一样进行。如果人没有预料到这种攻击发生，那么攻击就会持续保持隐秘性。
但是，通过定期监控媒体通道上是否有可以的传输，我们可以在对抗MiTM攻击的道路上前进一小步。正如前文所说，这可以与信令加密一同进行。
屏幕共享
任何可以提供不同程度屏幕共享的应用都应该弹出警示窗来保护用户的隐私。想之前提到过的，用户也许不会意识到他们所共享的范围到底是多大。这种问题可以通过在应用的设计过程中加入提示窗来解决，警示用户的共享范围。
举个例子，在推流任何屏幕部分之前，用户应该会得到合理的提示，并且应该被应用建议关掉所有包含敏感信息的窗口。
后备方法
作为最终的后备处理方法，我们想象在一个正活跃的通话已经暴露在未经授权的参与方面前。如果通话被证实了已经暴露，那么运用网页应用的力量就应该立刻切断通话。
参考文献[18]
7. 总结
在现在这个智能手机和移动设备广泛使用的时代。加密技术在近些年成为了一个很大的话题，也有很多大公司被窃听以及政府大范围电信窃听的丑闻传出。这导致了用户对这些公司或组织的不信任度迅速上升，并且要求安全性方面要有很大的提高。所有终端用户都想要知道他们的个人数据是否处于可控的私密范围内。
在安全性领域，WebRTC要远优于大多数VoIP服务。知道现在，很多服务通常都将安全性视为可有可没有的性能，意味着大多数终端用户使用VoIP的通话都没有被加密。通常大公司是这件事请的始作俑者，为了节省预算而不考虑他们所处理的用户数据的价值。但是因为WebRTC禁止未经加密的通信建立，用户可以放心他们的数据都是安全且私密的。
最初设计WebRTC时，安全性就是设计的目标之一，所以WebRTC强迫或者鼓励在所有主要部分中使用重要的安全性理念。同样因此，与简单的内置安全性一样，WebRTC也鼓励它的开发者严肃看待他们的安全性问题。
作为着重关注安全通信的结果，WebRTC目前被视为最安全的VoIP方案之一。默认进行加密的主要前提是通话在所有时候都是私密的。安全和加密不再被视为可选特性。并且WebRTC对于所有人来说都是免费的，给开发者提供了一个诱人的可靠的框架，用来搭建他们的下一个应用。
在不远的将来，我们可以期待看到越来越多的通信服务都可以给他们的用户提供大程度提高的安全保证。但是现在，WebRTC是这方面的领军者。
参考文献[19]
8. 参考目录
1. RTCPeerConnection API Reference.
developer.mozilla.org. Accessed on 2015-07-28.
2. Brief Introduction to RTCPeerConnection API.
High Performance Browser Networking. Accessed on 2015-07-28.
3. SDP for the WebRTC.
tools.ietf.org. Accessed on 2015-07-28.
4. After signaling: using ICE to cope with NATs and firewalls.
html5rocks.com. Accessed on 2015-07-28.
5. Getting Started with WebRTC – Security.
html5rocks.com. Accessed on 2015-07-28.
6. WebRTC Security – Same Origin Policy.
tools.ietf.org. Accessed on 2015-07-28.
7. Security Considerations for WebRTC.
tools.ietf.org. Accessed on 2015-07-28.
8. Attack of the week: Datagram TLS.
blog.cryptographyengineering.com. Accessed on 2015-07-28.
9. Web Real-Time Communication (WebRTC): Media Transport and Use of RTP.
tools.ietf.org. Accessed on 2015-07-28.
10. The Foundation of WebRTC Security.
onsip.com. Accessed on 2015-07-28.
11. WebRTC MUST implement DTLS-SRTP but… MUST NOT implement SDES?.
webrtchacks.com. Accessed on 2015-07-28.
12. IETF-87 rtcweb agenda.
tools.ietf.org. Accessed on 2015-07-28.
13. Security Considerations for WebRTC.
www.ietf.org. Accessed on 2015-07-28.
14. WebRTC and Man in the Middle Attacks.
webrtchacks.com. Accessed on 2015-07-28.
15. Security in a SIP network: Identifying network attacks.
searchunifiedcommunications.techtarget.com. Accessed on 2015-07-28.
16. Two attacks against VoIP.
symantec.com. Accessed on 2015-07-28.
17. Security for WebRTC applications.
altanaitelecom.wordpress.com. Accessed on 2015-07-28.
18. WebRTC Security.
altanaitelecom.wordpress.com. Accessed on 2015-07-28.
19. Why WebRTC is the Most Secure VoIP Solution.
bloggeek.me. Accessed on 2015-07-28.
