WebRTC安全研究

最新推荐文章于 2024-08-13 11:45:59 发布

雨声不在

最新推荐文章于 2024-08-13 11:45:59 发布

阅读量2.9k

点赞数 1

分类专栏： Android 文章标签： webrtc

Android 专栏收录该内容

257 篇文章 6 订阅

订阅专栏

原文地址：
https://webrtc-security.github.io/

概述

Web Real-Time Communication（缩写为WebRTC）是Web应用程序技术的最新趋势，它承诺能够在浏览器中实现实时通信，而无需插件或其他要求。

但是，该技术的开源特性可能会对该技术的潜在采用者造成与安全相关的问题。

本文将详细讨论WebRTC的安全性，旨在展示该技术的安全性。

简介

WebRTC是一种基于Web的开源应用程序技术，允许用户在不需要安装插件的情况下发送实时媒体。使用合适的浏览器可以使用户仅通过浏览相关网页就可以呼叫另一方。

该技术的一些主要用例包括：

实时音频和/或视频通话
网络会议
直接数据传输

与大多数实时系统（例如SIP）不同，WebRTC通信由某些Web服务器通过JavaScript API直接控制。

在没有插件的情况下在浏览器中实现嵌入式音频和视频通信的前景令人兴奋。然而，这自然引起了对这种技术的安全性的担忧，以及是否可以信任它为最终用户和任何中间运营商或第三方提供可靠的通信。

本报告将讨论这些主题并检查WebRTC提供的保护措施，以便在所有情况下提供安全性。

2. WebRTC架构概述

WebRTC使用对等（P2P）拓扑在两个对等体之间实现直接的富媒体通信。

WebRTC驻留在用户的浏览器中，无需其他软件即可运行。对等体之间的实际通信以元数据的交换开始，称为“信令”。该过程用于发起和通告呼叫，并促进不熟悉方之间的连接建立。

如图1所示，此过程通过中间服务器进行：

在这里插入图片描述

图1.一个简单的WebRTC调用拓扑

WebRTC中未指定信令协议，允许开发人员实现自己的协议选择。这允许在针对特定用例或场景调整WebRTC应用程序时具有更大程度的灵活性。

WebRTC通信如何工作？

WebRTC依赖于三个API，每个API执行特定功能，以便在Web应用程序中实现实时通信。将简要命名和解释这些API。每种协议和技术的实施和技术细节都超出了本报告的范围，但相关文档可在线获取。

getUserMedia

多年来，有必要依靠第三方浏览器插件（如Flash或Silverlight）从计算机中捕获音频或视频。然而，HTML 5时代已经引入了对众多设备的直接硬件访问，并提供了与系统底层硬件功能相连接的JavaScript API。

getUserMedia是一个这样的API，使浏览器能够访问用户的摄像头和麦克风。虽然WebRTC使用了这个API，但实际上它是HTML 5的一部分。

RTCPeerConnection

RTCPeerConnection是两个API中的第一个，它们是作为WebRTC规范的一部分提供的。 RTCPeerConnection接口表示实际的WebRTC连接，并且依赖于处理两个对等体之间的有效数据流。

当调用者想要启动与远程方的连接时，浏览器通过实例化RTCPeerConnection对象来启动。这包括自己生成的SDP描述以与其对等方交换。接收者依次使用自己的SDP描述进行响应。 SDP描述用作NAT遍历的完整ICE工作流程的一部分。

通过现在建立的连接，RTCPeerConnection可以将实时音频和视频数据作为浏览器之间的比特流发送。

最终，RTCPeerConnection API负责管理每个对等连接的整个生命周期，并在一个易于使用的界面中封装所有连接设置，管理和状态。

RTCPeerConnection有两个特定的特征： - 两个浏览器之间的直接对等通信 - 使用UDP/IP- 不保证数据包到达（如在TCP/IP中），但结果会大大减少开销。（通过允许丢失一些数据，我们可以专注于提供实时通信。）

RTCDataChannel

RTCDataChannel是作为WebRTC的一部分提供的第二个主要API，它代表了在对等体之间进行任意应用程序数据交换的主要通信通道。换句话说，它用于将数据直接从一个对等方传输到另一个对等方。

尽管存在许多用于通信信道的备选选项（例如，WebSocket，服务器发送事件），但是这些备选方案被设计用于与服务器而不是直接连接的对等体通信。 RTCDataChannel类似于流行的WebSocket，而是采用点对点格式，同时提供底层传输的可自定义传递属性。

2.1 基础技术

三个主要的API是面向开发人员的WebRTC方面，但是为了提供这些协议（RTCPeerConnection和RTCDataChannel API），有许多基础技术被使用。

在这里插入图片描述
图2. WebRTC协议栈

ICE，STUN和TURN是建立和维护UDP上的对等连接所必需的。 DTLS用于保护对等体之间的所有数据传输，因为加密是WebRTC的强制功能。最后，SCTP和SRTP是用于复用不同流，提供拥塞和流量控制，并在UDP之上提供部分可靠传送和其他附加服务的应用协议。

SDP：会话描述协议

会话描述协议（SDP）是一种描述性协议，用作宣布和管理会话邀请以及执行多媒体会话的其他启动任务的标准方法。 SDP以基于文本的格式表示浏览器功能和首选项，可能包括以下信息： - 媒体功能（视频，音频）和使用的编解码器 - IP地址和端口号 - P2P数据传输协议（WebRTC使用SecureRTP） - 可用于通信的带宽 - 会话属性（名称，标识符，活动时间等） - >但是WebRTC中不使用这些属性。 - 其他相关元数据…

截至目前，SDP广泛用于会话发起协议（SIP），实时传输协议（RTP）和实时流协议（RSP）的上下文中。

ICE：交互式连接建立
信令需要初始使用中间服务器来交换元数据，但在完成后，WebRTC尝试在用户之间建立直接的P2P连接。该过程通过ICE框架进行。

ICE是用于在因特网上建立连接之间的连接的框架。尽管WebRTC试图利用直接P2P连接，但实际上NAT（网络地址转换）的广泛存在使得很难协商两个对等体如何通信。

由于IPv4地址持续广泛流行且其32位表示有限，因此大多数支持网络的设备没有唯一的面向公众的IPv4地址，可以在Internet上直接显示该地址。 NAT通过在出站请求通过时将私有地址动态转换为公用地址来工作。同样，对公共IP的入站请求也会转换回专用IP，以确保在内部网络上进行正确的路由。结果，共享私有IP通常不足以建立与对等方的连接。 ICE试图克服通过NAT进行通信所带来的困难，以找到连接对等体的最佳途径。

通过并行尝试所有可能性，ICE能够选择最有效的选项。 ICE首先尝试使用从设备的操作系统和网卡获得的主机地址建立连接; 如果失败（对于NAT后面的设备不可避免地会出现这种情况），ICE会使用STUN服务器获取外部地址。如果这也失败了，流量将通过TURN中继服务器回退到路由。

候选通信路由以基于文本的格式呈现，并且列表按优先级排序。选项采用以下形式之一： - 直接P2P通信 - 使用STUN，具有NAT遍历的端口映射（此路由最终解析为直接P2P通信） - 使用TURN作为中介（此配置使用中继通信而不是P2P）

在所有可能的候选者中，选择具有最小开销的路线。

STUN：NAT的会话遍历实用程序
为了执行P2P通信，双方必须至少知道其对等方的IP地址和分配的UDP端口。因此，在建立WebRTC通信之前，必须进行一定量的信息交换。

每个对等体使用STUN服务器来确定它们的公共IP地址，并在连接建立期间由ICE框架引用。 STUN服务器通常可以公开访问，并且可以由WebRTC应用程序自由使用。

TURN：使用NAT周围的继电器进行遍历
在建立P2P通信失败的可能性中，可以通过TURN服务器提供后备选项。通过在对等体之间中继流量，可以确保WebRTC通信，但是可能遭受媒体质量和延迟的降级。

无论最终用户的环境如何，TURN服务器都可以确保呼叫质量。当数据通过中间服务器发送时，也会消耗服务器带宽。如果同时通过服务器路由多个呼叫，则带宽也变得相当大。

服务器本身通常不可自由访问，并且必须由应用程序提供商专门提供（或租用）。

3.基于浏览器的安全注意事项

有许多方法可以使实时通信应用程序对运营商和最终用户施加安全风险。此类安全风险可适用于处理实时数据和媒体传输的任何应用程序。

WebRTC与其他RTC应用程序的不同之处在于，即使是新开发人员也可以在不影响安全性的情况下使用强大而可靠的基础架构。我们现在将讨论WebRTC如何依次处理这些风险。

参考文献：[ 5 ]

3.1 浏览器信任模型

WebRTC体系结构从安全角度假设网络资源存在于信任层次结构中。从用户的角度来看，浏览器（或用户客户端）是所有WebRTC安全性的基础，并充当其可信计算基础（TCB）。

浏览器的工作是启用对互联网的访问，同时为用户提供足够的安全保护。 WebRTC的安全要求直接建立在这个要求之上; 浏览器是用户通过其访问所有WebRTC应用程序和内容的门户。

虽然服务器提供的HTML和JS可以使浏览器执行各种操作，但浏览器会将这些脚本分隔为沙箱。所述沙箱将脚本彼此隔离，并从用户的计算机隔离脚本。一般来说，脚本只允许与来自同一域的资源进行交互 - 或者更具体地说，是相同的“来源”。

浏览器强制执行用户期望的所有安全策略，并且是验证所有第三方的第一步。所有经过身份验证的实体都会通过浏览器检查其身份。

如果用户选择他们知道可以信任的合适浏览器，那么所有WebRTC通信都可以被认为是“安全的”并遵循WebRTC技术的标准接受安全架构。但是，如果确定浏览器是“可信任的”（例如，已从第三方而非受信任位置下载），则与WebRTC应用程序的所有后续交互都会受到影响，并且可能无法可靠地保护。

换句话说，WebRTC提供给用户的信任级别直接受用户对浏览器的信任的影响。

3.2 SOP：同源政策

DOM的一个基本方面是，无论何时加载部分或全部页面，都从页面的Web服务器获取所有网页资源。当浏览器新加载页面时，或者当驻留在网页上的脚本发出这样的请求时，都会获取资源。这样的脚本很容易通过例如XMLHttpRequest（）API发出HTTP请求，但是不允许这些请求只发送给他们指定的任何服务器。相反，必须从脚本起源的相同“原点”进行请求。 “origin”包括URI方案，主机名和端口号。这种整体限制被称为“同源政策”（SOP）。

SOP强制脚本在特定于其原始域的隔离沙箱中执行，从而防止来自不同来源的页面甚至同一页面上的iframe交换信息。来自同一源服务器的网页和脚本在与彼此的JS变量交互时保持不受阻碍。因此，起源构成了网络沙箱的基本单元。

通过基于每个来源强制执行沙箱，最终用户可以免受滥用其凭据的影响。您可以合理地期望安全地使用社交网站，而无需在广告面板内执行脚本并窃取您的登录信息。

类似地，保护例如网页提供者的服务器免受通过用户的浏览器安装的攻击; 如果不存在此类安全措施，则可以通过滥用资源请求启动DoS攻击。

3.2.1绕过SOP

SOP对于用户和Web服务器的安全性一般都非常重要，尽管它确实具有使某些类型的Web应用程序难以创建的缺点。确实存在允许站点间交互的方法，尽管这些方法通常是相互同意的并且限于某些渠道。

W3C跨源资源共享（CORS）规范是该问题的答案之一。它允许浏览器联系脚本的目标服务器以确定它是否愿意参与给定类型的事务。因此，通过为目标服务器提供专门选择加入某些请求并拒绝所有其他请求的选项，可以安全地允许跨源请求。

WebSockets是允许类似功能的另一种选择，但是在透明通道而不是隔离的HTTP请求上。一旦建立了这样的连接，脚本就可以根据需要传输流量和资源，并且需要将其构建为一系列HTTP请求/响应事务。

在这两种情况下，初始验证阶段都会阻止具有不同来源的脚本进行任意数据传输。

4. WebRTC安全注意事项

4.1 安装和更新

传统桌面软件的一个普遍问题是人们是否可以信任应用程序本身。安装新软件或插件可能会偷偷安装恶意软件或其他不受欢迎的软件。许多最终用户不知道软件的制作地点，也不知道他们从哪里下载应用程序。

但是WebRTC不是插件，也没有任何组件的安装过程。所有底层WebRTC技术仅作为下载合适的WebRTC兼容浏览器（如Chrome或Firefox）的一部分安装。如果用户有这样的浏览器，他们可以浏览并使用任何WebRTC应用程序，而无需其他设置或准备。因此，通过使用适当的WebRTC应用程序不存在安装恶意软件或病毒的风险。但是，仍应通过由有效身份验证器（如Verisign）签名的HTTPS网站访问WebRTC应用程序。

另一个相关的考虑因素是修补软件中发现的安全漏洞。与任何软件技术一样，完全有可能在WebRTC中发现未来的漏洞或漏洞。如果在传统桌面应用程序（例如典型的VoIP应用程序）中发现漏洞，则修补程序的开发可能需要相当长的时间。这是应用程序开发的常见问题，因为安全性仍然经常被视为功能之后的次要考虑因素。比这更深入，我们可以考虑基于硬件的通信方法。 VoIP电话多久获得一次安全更新？您能否相信负责人定期更新？你甚至知道谁负责吗？

与此相反，由于用户所面临的风险的频率和范围，以及它们无处不在的性质（以及通过浏览器访问的信息的重要性），浏览器是一个快节奏的开发场景。由于WebRTC的组件是作为浏览器的一部分提供的，因此无论何时更新浏览器，它们都会更新。如果在浏览器的WebRTC实现中发现未来的漏洞，则可能会快速提供修复。在Chrome和Firefox的快速开发周期中尤其如此。事实上，在自动更新的时代，只要服务器上的补丁可用，就可以通过新的浏览器版本更新WebRTC组件。大多数现代浏览器都能在发现严重漏洞或威胁后的24小时内自行更新。

作为旁注：尽管我们已经声明WebRTC不需要安装插件，但第三方WebRTC框架可能提供插件以支持当前不支持的浏览器（例如Safari和IE）。在这种情况下，建议用户注意（或支持的浏览器）。

4.2 访问媒体/本地资源

浏览器可以访问本地资源（包括摄像头，麦克风，文件），这导致Web应用程序访问用户的麦克风和摄像头时不可避免的问题。如果Web应用程序可以自由访问用户的摄像头或麦克风，则不道德的应用程序可能会在用户不知情的情况下尝试录制或分发视频或音频源。驻留在后台标签中的网站滥用用户的信任可能是一件简单的事情（用户可能甚至没有意识到网站包含这样的通信应用程序）。

WebRTC通过要求用户明确允许使用相机或麦克风（两者都可以单独配置）来解决这个问题。可以要求用户进行一次性或永久性访问。 WebRTC应用程序无法任意访问或操作任一设备。此外，当使用麦克风或相机时，客户端UI需要明确地向用户显示麦克风或相机正在被操作。在Chrome中，这会在访问用户媒体的任何标签上采用红点的形式。

这种安全保护的理念是，用户应始终就是否允许呼叫发生或接听电话做出明智的决定。换句话说，用户必须了解： - 谁或什么请求访问他的媒体 - 媒体的去向 - 或两者兼而有之。

作为附加规定，WebRTC规范规定，当UI指示符被屏蔽时（例如，通过窗口重叠），浏览器应该停止相机和麦克风。虽然这更像是一种理想的行为，但并不一定能得到保证，用户应谨慎行事。但幸运的是，这种附加功能不太可能是用户期望的行为。

由于范围的固有灵活性，屏幕共享引入了进一步的安全性考虑。用户可能不会立即意识到他们共享的信息的范围。例如，他们可能认为他们只是共享特定窗口的流（例如，在向远程方提供演示时），而实际上他们正在向他们的观众展示他们的整个屏幕。这可能是用户未能正确建立初始屏幕共享设置的结果，或者用户可能只是忘记了他们共享的范围。

4.3 媒体加密和通信安全

有许多方法可以使实时通信应用程序产生安全风险。一个特别值得注意的是在传输期间拦截未加密的媒体或数据。这可能发生在浏览器浏览器或浏览器 - 服务器通信之间，窃听的第三方能够看到发送的所有数据。然而，加密使得窃听者有效地无法确定通信流的内容。只有访问秘密加密密钥的各方才能解码通信流。

加密是WebRTC的强制功能，并在所有组件上实施，包括信令机制。结果，通过WebRTC发送的所有媒体流都是安全加密的，通过标准化和众所周知的加密协议制定。使用的加密协议取决于信道类型; 使用数据报传输层安全性（DTLS）对数据流进行加密，并使用安全实时传输协议（SRTP）对媒体流进行加密。

4.3.1 DTLS：数据报传输层安全性

WebRTC使用数据报传输层安全性（DTLS）加密信息（特别是数据通道）。通过RTCDataChannel发送的所有数据都使用DTLS进行保护。

DTLS是一种标准化协议，内置于支持WebRTC的所有浏览器中，是Web浏览器，电子邮件和VoIP平台中一致使用的一种协议，用于加密信息。内置特性也意味着在使用前无需事先安装。与其他加密协议一样，它旨在防止窃听和信息篡改。 DTLS本身是以流为导向的TLS建模的，TLS是一种通过非对称加密方法，数据认证和消息认证提供完全加密的协议。 TLS是Web加密的事实标准，用于HTTPS等协议。 TLS是为TCP的可靠传输机制而设计的，但VoIP应用程序（和游戏等）通常使用不可靠的数据报传输，例如UDP。

由于DTLS是SSL的衍生产品，因此已知所有数据都与使用任何基于标准SSL的连接一样安全。实际上，WebRTC数据可以通过Web上的任何基于标准SSL的连接来保护，允许WebRTC在几乎任何服务器安排的对等体之间提供端到端加密。

4.3.1.1 DTLS over TURN

所有WebRTC通信的默认选项是两个浏览器之间的直接P2P通信，在设置阶段辅助信令服务器。 P2P加密相对容易设想和设置，但是在失败的情况下，WebRTC设置回退到通过TURN服务器（如果可用）进行通信。在TURN通信期间，媒体可能遭受质量损失和延迟增加，但它允许“如果所有其他都失败”的情况允许WebRTC应用程序即使在具有挑战性的情况下也能工作。我们还必须考虑TURN的替代通信结构下的加密通信。

众所周知，无论通信方法如何，发送的数据都在端点加密。 TURN服务器的目的仅仅是在呼叫中各方之间中继WebRTC数据，并且仅解析WebRTC分组的UDP层以用于路由目的。服务器不会解码应用程序数据层以便路由数据包，因此我们知道他们不会（也不能）触摸DTLS加密。

因此，在通过TURN进行WebRTC通信期间，通过加密实施的保护不会受到损害，并且服务器无法理解或修改对等方发送给彼此的信息。

4.3.2 SRTP：安全的实时传输协议

基本RTP没有任何内置的安全机制，因此不保护传输数据的机密性。相反，依赖外部机制来提供加密。实际上，WebRTC规范明确禁止使用未加密的RTP。

WebRTC利用SRTP加密媒体流，而不是DTLS。这是因为SRTP是比DTLS更轻的选项。该规范要求任何兼容的WebRTC实现都支持RTP / SAVPF（它建立在RTP / SAVP之上） [ 9 ] 。但是，实际的SRTP密钥交换最初是使用DTLS-SRTP端到端执行的，允许检测任何MiTM攻击。

4.3.3 建立安全链接

让我们逐步完成在WebRTC应用程序上建立新调用的过程。在这种情况下，将涉及两方; 爱丽丝和鲍勃。当一方（Alice）呼叫另一方（Bob）时发起呼叫过程，并且信令过程在双方之间交换相关元数据。

一旦初始ICE检查结束（或具体地，其中一些），两个对等体将开始设置一个或多个安全信道。最初，在ICE建立的所有信道上执行DTLS握手。对于数据通道，仅使用简单的DTLS进行加密就足够了。然而，对于媒体频道，采取进一步的步骤。

DTLS握手完成后，密钥将“导出”并用于键入媒体通道的SRTP。在这个阶段，双方都知道他们共享一组安全数据和/或媒体频道，这些频道具有任何恶意第三方都不知道的密钥。

4.3.4。 DTLS-SRTP与SDES

为了协商媒体流量会话的安全参数，SRTP需要与密钥管理协议进行交互。该协议尚未建立，为该任务提供了许多可能的选项。两个这样的选项是SDES和DTLS-SRTP。

值得注意的是，可以独立地保护多媒体通信中涉及的信令（SIP，HTTP）和媒体（RTP）。

SDES

媒体流的SDP安全描述（SDES）是之前WebRTC青睐的选项。

在SDES中，用于设置SRTP会话的安全参数和密钥以SDP属性的形式以明文形式交换。当SDP通过信令平面传送时，如果没有在这种信令消息上另外实施加密，则窃听第三方可以获得SDES加密数据的密钥。换句话说，应该专门用于信令平面的加密的另一加密协议。对此的一个这样的选择是使用TLS。

然而，独立地保护信令和媒体可能导致媒体用户与信令用户不同的情况（因为不提供保证）。要提供此保证，必须使用加密绑定。 DTLS-SRTP是提供此功能的一种机制，但SDES不提供此功能。

事实上，即使在今天，VoIP网络中的大多数RTP流量也不安全。事实上，加密是客户通常要求供应商删除以满足其预算的首要功能之一。在安全的情况下，大多数部署都使用SDES，正如我们刚刚提到的那样，SDES在很大程度上依赖于信令平面安全性。

DTLS-SRTP

另一方面，DTLS-SRTP通过媒体平面而不是信令平面交换密钥。这种差异的结果是SRTP媒体信道不需要通过SDP消息交换来揭示秘密加密密钥，如SDES的情况。

WebRTC规范[ 9 ]断言，WebRTC实现需要支持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报头中的一条这样的信息是所包含的媒体数据的音频级别。实际上，任何能够看到SRTP数据包的人都可以在任何给定时间判断用户是否在说话。虽然媒体本身的内容对任何窃听者来说都是秘密，但这仍然是一个可怕的前景。例如，执法官员可以确定用户是否正在与已知的坏人进行通信。

4.4。基于Web的对等身份验证和身份管理

期望用户能够验证他们的同伴的身份。即，用户自然希望确定他们正在与他们认为他们正在与之交谈的人说话，而不是冒名顶替者。

尽管信令服务器可能能够某种方式来声明用户的身份，但是信令服务器本身可能不会（并且对于认证的情况不应该）被信任。我们需要能够独立于信令服务器执行对等体的认证。这可以通过使用身份提供者来实现。

在这里插入图片描述
图4.基于IdP身份的呼叫
最近，许多基于网络的身份提供商（IdP）在网络上变得司空见惯，包括Facebook Connect，BrowserID（Mozilla），OAuth（Twitter）。这些机制的目的只是在身份提供者本身的权限下验证您对其他服务/用户的身份。如果用户在Facebook上拥有一个帐户，那么他们可以使用Facebook Connect，Facebook的IdP向其他人证明他们是他们所说的他们在Facebook上的人。这允许用户将其他服务上的身份验证与“受信任”服务上的主帐户绑定。请注意，在这种情况下，身份提供商拥有的“信任”级别对于终端用户或服务来说是主观的，并且通常主要与万维网上的用户群和声誉相关联。

由于不同公司的独立开发而不是基于开源标准，每个IdP的实现可能不同，但基本原理和功能基本保持不变。 IdP不为信令服务器提供身份验证; 相反，它们为用户（以及他们的浏览器通过该过程）提供身份验证。 WebRTC也没有要求使用哪些服务，而且使用的服务基于Web应用程序的实现。

由于Web应用程序（调用站点）与此身份验证过程无关，因此浏览器安全地生成身份验证过程的输入并安全地在Web应用程序上显示输出非常重要。此过程不得被Web应用程序伪造或歪曲。

在这里插入图片描述
图5.身份提供者的操作

4.5 IP位置隐私

使用ICE的一个不利副作用是对等方可以获得另一个人的IP地址。由于IP地址是向全球权威机构公开注册的，因此可以将这些详细信息显示为给定对等方的位置。这自然会对他们希望避免的同伴产生负面影响。

WebRTC的设计目的不是保护用户免受想要学习此信息的恶意网站的侵害。通常，这样的站点将从任何HTTP事务中至少学习用户的服务器自反地址。隐藏服务器的IP地址需要在客户端上使用某种显式的隐私保护机制，这超出了本报告的范围。

然而，WebRTC提供了许多机制，这些机制旨在允许Web应用程序与用户合作以从呼叫的另一侧隐藏用户的IP地址。这些机制将依次详述。

需要WebRTC实现来提供一种机制，允许JS在用户决定接听呼叫之前抑制ICE协商。此规定可帮助最终用户阻止对等方在他们选择不接听电话时学习其IP地址。这具有隐藏用户是否在线对等的副作用。

第二个这样的规定是任何实现都将为调用应用程序的JavaScript提供一种机制，以指示仅使用TURN候选者。这可以防止对等体完全学习一个IP地址。

此外，还有一种机制，用于呼叫应用程序重新配置现有呼叫以添加非TURN候选者。与先前的规定一起，这允许ICE协商在来电通知时立即开始，从而减少延迟，但也避免在他们决定回答之前公开用户的IP地址。这允许用户在呼叫期间完全隐藏其IP地址。

4.6 信令层

由于WebRTC未指定信令协议，因此加密机制显然取决于所选择的信令协议。由于信令安全性相对开放，本报告将重点介绍最简单的协议SIP（会话启动协议）。

SIP是一种广泛实施的标准，用于VoIP通信以建立和拆除电话呼叫。但是，它是HTTP和SMTP的衍生产品 - 两者都是经常被利用的协议。由于它使用纯文本消息来交换信息，因此任何恶意方都可以使用网络并捕获SIP消息。如果攻击者可以读取用户的敏感信息，他们可以使用此信息来欺骗用户。如果攻击者可以进一步访问运营商的网络，他们甚至可以破译WebRTC通信的内容。 [ 14 ]

由于SIP是以明文形式发送的，因此确定的攻击者拦截SIP消息是微不足道的。接下来发生的事情取决于攻击者的想象力，但不难想象消息体或标题的内容被篡改的可能性。如果攻击者拦截INVITE消息，则他们可以继续更改FROM头以反映他或她自己的IP地址。

4.6.1 SIP漏洞

SIP是用于发信号通知和控制多媒体通信会话的通信协议，并且经常在VoIP技术中实现，以便建立和拆除电话呼叫。它可以类似地在WebRTC实现中用于信令目的，作为许多可能的这样的选项之一。但是，SIP消息通常以纯文本形式发送。由于这自然会导致许多潜在的攻击向量，我们将对该区域进行更仔细的检查。

SIP流程

在建立呼叫的过程中，用户的浏览器（或“用户代理”）向中央注册器注册。这种注册在传统VoIP中是必需的，因为必须提供定位和联系远程方的手段。

当一方（Bob）想要发起呼叫时，他通过中央代理服务器（这是信令服务器）发送INVITE消息。服务器负责中继此类消息，并提供定位其他用户的方法。服务器可以尝试许多措施以在该查找过程期间定位最终用户，例如利用DNS。

注册劫持

初始浏览器注册用于通知用户的联系点，并指示用户的设备正在接受呼叫。但是，该过程为恶意实体提供了一个执行“注册劫持”攻击的向量。

注册消息的交换包括“联系人：”字段，其中包含用户的IP地址。每当信令服务器处理来电时，用户名（或电话号码）与注册的IP地址匹配，并相应地转发INVITE。这些注册会定期更新，确保记录保持最新和最新。

由于SIP消息总是以纯文本形式发送，因此攻击者拦截和读取这些注册消息的内容可能是微不足道的。拦截之后，可以使用适当的工具（例如SiVuS消息生成器）生成类似的SIP信息，但用户的真实IP地址由攻击者自己的IP地址替换。然后，攻击者只需要禁用真实用户并定期发送此信息，以将所有来电转移到自己。

攻击者可以通过多种方法来禁用合法用户，包括： - 对用户的设备执行DoS攻击 - 取消注册用户（此处未涉及的另一种攻击） - 生成注册竞争条件，攻击者在较短的时间范围内（例如每15秒）重复发送REGISTER请求，以覆盖合法用户的注册请求。这对WebRTC信令服务都是真正的风险。

由于SIP的实现不支持消息内容的检查完整性，因此不会检测到修改和重放攻击，并且是可行的攻击向量。即使服务器要求对用户注册进行身份验证，此攻击也会起作用，因为攻击者可以根据需要再次捕获，修改和重播消息。

可以通过实施SIPS（SIP over TLS）和验证SIP请求和响应（可以包括完整性保护）来抑制此攻击。实际上，SIPS的使用和响应的认证可以抑制许多相关的攻击，包括窃听和消息或用户模仿。

其他可能的攻击

MiTM攻击

如果攻击者能够拦截初始SIP消息，则他或她可以执行MiTM攻击。
重播攻击

被捕获的数据包可能被恶意方重播到服务器，导致服务器呼叫呼叫的原始目的地。换句话说，这可能采取第二个未经请求的呼叫请求的形式，与该方已经收到的请求相同。虽然令人讨厌，但攻击者不会成为呼叫的一方，因为他们的IP信息不会包含在信令数据包中。
会话劫持

Web服务器不是有状态的，每个请求都是单独的会话（减少了连续身份验证的需要）。用于身份验证的Cookie，但只不过是包含会话ID的数据文件。这些cookie在初始访问时由Web服务器发送到浏览器。
如果要拦截和复制cookie，它可以允许拦截器完全访问正在进行的会话。为了缓解这种情况，大多数站点使用涉及用户IP地址和时间戳的算法生成cookie以创建唯一标识符。

加密

虽然看起来信号可能为攻击者提供了一个特别诱人的有利位置，但并不会丢失所有信号。除了媒体流之外，还可以加密信令层。一个这样的加密选项是OnSIP，它使用SIP over Secure WebSockets（wss：//而不是ws：//），其中WebSocket连接由TLS加密。

虽然在本报告的范围之外，其他信令技术可以类似地使用TLS来加密其WebSocket或其他Web流量。与所有加密一样，如果第三方不知道秘密加密密钥，则它们因此无法读取通信的明文内容。这有助于消除上述大部分攻击媒介的风险，但应注意应用程序员必须专门实施加密信令方法才能适用。

4.7。其他安全主题

电信网络的观点

通过为WebRTC提供支持，电信网络应该合理地预期不会面临更高的安全风险。但是，消费者手中的设备或软件将不可避免地受到恶意方的侵害。

因此，必须验证从不可信来源（例如来自消费者/用户）接收的所有数据，并且电信网络必须假定发送到客户端的任何数据将由恶意源获得。

通过采用这两个原则，电信提供商必须努力做出一切合理的尝试，以保护消费者免受可能危及他们自己系统的错误。

跨站脚本（XSS）

跨站点脚本是一种类型漏洞，通常在Web应用程序（例如通过浏览器安全性破坏的Web浏览器）中发现，使攻击者能够将客户端脚本注入其他用户查看的Web页面。攻击者可能会使用跨站点脚本漏洞绕过访问控制，例如相同的源策略。

它们的影响可能从轻微的麻烦到重大的安全风险，取决于易受攻击的站点处理的数据的敏感性以及站点所有者实施的任何安全缓解的性质。

由于访问WebRTC的主要方法是使用支持HTML5的浏览器，因此有关于其使用的特定安全注意事项，例如：保护密钥和敏感数据免受跨站点脚本或跨域攻击，WebSocket使用，iframe安全性和其他问题的影响。 - 因为客户端软件将由用户控制，并且因为浏览器不会在大多数情况下在受保护的环境中运行，所以WebRTC客户端将有更多机会受到攻击。这意味着可以公开发送到客户端的所有数据。

5.与竞争/类似技术的比较

如果不考虑竞争的安全性，对WebRTC的比较安全性的检查就没有意义。幸运的是，对于WebRTC来说，基于网络的通信领域的竞争有其自身的一些问题。

本节将探讨WebRTC和其他提供竞争RTC功能的平台的比较优势和劣势。

我们可以探索的一些平台如下。尚未选择要探索的平台。（在初稿之后来。）

6.安全的设计实践

WebRTC旨在确保安全。然而，不仅仅是盲目地依赖底层技术，有意识地编写安全性代码是一个好主意。本节将讨论可以遵循的编码实践，以确保对vanilla WebRTC实现的更高安全性。特别是，这些做法可适用于希望处理敏感信息的组织，例如银行机构，医疗机构或机密公司信息。

安全信令

如前所述，WebRTC不对信令过程施加任何限制，而是让开发人员决定他们自己的首选方法。虽然这允许一定程度的灵活性，可以根据应用程序的需要定制WebRTC实现，但是某些信令协议可能存在风险。

建议实施提供额外安全性的信令协议，例如信令流量的加密。默认情况下，信令进程可能不包含任何加密，这可能使所有交换的信令消息的内容保持开放以进行窃听。因此，关注安全性/机密性的应用应确保其信令层通过SIPS，OpenSIP，HTTPS或WSS等安全协议实现。

身份验证和对等监控

基本的WebRTC应用程序只需要用户的ID即可执行呼叫，而不会从服务本身的角度执行身份验证。在任何用户可以参与呼叫之前，可能需要预先注册或认证。然后，未经身份验证的实体应远离会话范围，从而限制对不受信任方的访问。

由于媒体连接是P2P，因此媒体内容（音频和视频信道）直接以全双工在对等体之间传输。因此，当信令服务器维持通信中的对等体的数量时，可以一致地监视它以在呼叫会话中添加可疑对等体。如果信令服务器上实际存在的对等体的数量多于在WebRTC页面上交互的对等体的数量，则可能意味着某人正在秘密窃听并且应该通过强制终止会话访问。

许可请求

这是一种值得注意的行为，用户通常会在不自觉阅读消息的情况下同意许可请求或类似对话。这带来了授予具有用户实际上不想要的权限的Web应用程序的风险。

虽然这种行为本身不易处理，但一种解决方案可能是在页面上清楚地详细说明应用程序要求的权限。这样的应用程序将用户的隐私置于最前沿。

在这方面的中间人

在恶意方成功设置MiTM攻击的情况下，通常没有一种简单的解决方案可以发现或反对它。这是因为攻击没有警告，并且允许通信正常进行。如果不期待这样的攻击，攻击可能会继续被忽视。

但是，通过定期监控媒体路径，没有可疑的中继，我们可以采取一小步措施来减轻MiTM攻击。如上所述，这应该与加密信令耦合。

屏幕共享

提供任何程度的屏幕共享功能的应用程序应该有警告来保护用户。如前所述，用户可能不知道共享屏幕的范围。这样的问题应该归结为适当设计的应用程序，以提供适当的此类信息。

例如，在启动屏幕的任何部分的流式传输之前，应该正确地通知用户并建议关闭包含敏感信息的任何屏幕。

后备措施

作为最后的后备措施，我们可以冒险尝试一种情况，即一个活跃的呼叫会话被未经授权的一方泄露。如果确认呼叫以这种方式被泄露，则应该在Web应用程序服务器的强大功能内呈现具有WebRTC功能的页面以切断呼叫。

7.结论

在现代智能手机和移动设备时代，人们比以往任何时候都更加沟通，而且比以前更加个性化。随着人们越来越意识到主要的公司黑客丑闻和广泛的政府电信窃听，加密尤其成为近年来的一个大话题。其结果是用户对这些组织的不信任迅速增加，并要求武器实施大大改进的安全措施。所有最终用户想要知道他们的个人数据在私人控制下是私有的。

WebRTC与安全领域的大多数VoIP服务相比具有很大的优势。到目前为止，大多数服务通常将安全性视为可选，这意味着大多数最终用户使用VoIP呼叫而不加密。特别是大公司是这方面的罪魁祸首，选择在更便宜的实施上省钱，而不是正确考虑他们的用户或他们处理的数据的价值。但是，由于WebRTC禁止未加密的通信，用户可以放心，他们的数据仍然是安全和私密的。

WebRTC在设计时考虑了安全性，在所有主要领域强制执行或鼓励重要的安全概念。因此，它只是简单地构建安全，它鼓励WebRTC开发人员也认真对待他们的安全性。

由于对安全通信的强烈关注，WebRTC目前被一些人认为是最安全的VoIP解决方案之一。默认情况下加密的主要前提是呼叫始终是私有的。安全性和加密不再被视为可选功能。为了解决所有问题，WebRTC可供所有人免费使用，为开发人员构建下一个应用程序提供了一个诱人而可靠的框架。

在不久的将来，我们可以期待看到越来越多的通信服务为其用户提供极大的安全性。但就目前而言，WebRTC是领导这项指控的人之一。