WebRTC安全体系架构的8个组件

正文字数：2955 阅读时长：4分钟

WebRTC不仅仅是为低延迟实时流媒体传输而设计的。为了满足现代流媒体应用程序的需求，WebRTC还提供了流安全性。本文主要研究WebRTC的安全体系结构以及如何设置它。

Written By Red5Pro

url : https://www.red5pro.com/blog/webrtc-security-architecture/

数据加密

首先，需要指出的是，WebRTC流始终是加密的。

加密是一种对数据进行处理的方式，以便只有授权方才能理解该信息。用技术术语来说，它是将明文转换成密文的过程。简单地说，加密获取可读数据并对其进行修改，使其看起来是随机的。这个过程中需要使用两个加密密钥。一个公共密钥和一个私有密钥。这些密钥是加密消息的发送者和接收者都可以解密的一组数学值。加密需要是随机的，以防止未经授权的用户访问数据，以防止未经授权的用户访问数据，但对于接收信息的授权方来说是可预测的，以便正确使用。

由于WebRTC直接在浏览器中工作，这意味着加密过程也可以在浏览器中执行，而无需其他配置。此外，WebRTC不需要下载任何其他插件。这进一步提高了安全性，因为它消除了第三方软件带来得影响以及诸如数据跟踪或病毒之类的潜在副作用得担忧。插件也是另一个潜在的安全风险，因为它们是可以利用的附加连接。

WebRTC安全性实现了基于AES（高级加密标准）的保护。这样，就消除了使用第三方或利用DIY平台来管理与身份验证设备和授权用户相关的所有功能的风险。相反，WebRTC使用视频传输协议SRTP（安全实时协议）通过WebRTC专门用于视频，音频和数据的三个通道来发送和接收加密内容。

SRTP用于加密和解密内容的密钥的交换是通过IETF的TLS版本（称为DTLS（数据报传输层安全性Datagram Transport Layer Security））进行管理的，该版本与UDP（用户数据报协议）连接一起使用，UDP是WebRTC采用的超低延迟包传输协议。尽管我们描述使用UDP是因为这是使用WebRTC的典型设置，但应注意的是，同样的过程也可以通过TCP来完成。所有这一切都会随着WebRTC流的实例化而自动发生。稍后将更详细地介绍这一点。

此外，无论使用那种托管服务提供商，都将复制相同的WebRTC安全体系结构。支持跨云解决方案的能力提高了灵活性。由于WebRTC安全实施是标准的，因此它还可以在不同区域中建立相同的安全功能特性。

加密可确保无法读取广播者和订户之间发送的数据。接下来的部分将首先介绍如何建立连接。

信号和CORS

CORS（cross-origin resource sharing跨资源网络共享）可防止不必要的信息在网站和其他资源（如服务器、数据中心或其他网站）之间交换。这是一个W3C标准，它提供了一个过程，在这个过程中，服务器和网站可以交互，以确定允许通过跨源请求传输数据是否安全。

CORS也会影响WebRTC在实时流媒体中的使用。具体地说，关于在广播机或订阅客户端与相应的服务器之间建立连接，该服务器将充当两者之间的中继点，用WebRTC的说法称为“信令”。

为了让一个流连接到另一个对等端，它们需要知道在哪里可以找到彼此。如果连接的两端不在同一个web服务器上提供服务，CORS限制将阻止建立连接。在这种情况下，连接必须通过信令协议进行协商。WebRTC规范没有指定如何发送这些信令消息，因此可以通过HTTP或WebSockets发送。无论哪种方式，连接到服务器进行信号发送，都需要处理CORS及其提供的配置。Red5Pro用WebSockets实现信令。在我们的Red5Pro自动缩放集群中，流管理器（Stream Manager）充当信令服务器，将调用向下代理到边缘和源节点，以建立从WebRTC客户端到这些服务器节点的连接。下图显示了此关系以及将WebRTC发布服务器客户端连接到源节点的流管理器。

HTTPS和安全WebSockets (WSS)

要从浏览器创建视频，浏览器必须能够访问摄像机和麦克风。在Chrome中，这是通过getUserMedia方法实现的，只有在安全网站上提供服务时，才能访问该方法。由于HTML页面必须通过HTTPS传输到浏览器，这也意味着从该页面与您通信的任何服务器也必须是安全的。

通过HTTPS传输站点内容有两个要求：1）访问站点的域名，2）web服务器上安装的已验证提供商提供的证书。使用域名，浏览器根据它信任的提供程序所提供的证书验证域。验证后，将在浏览器和服务器之间执行密钥交换，以允许SSL加密。一旦加密，页面将不会以纯HTML/JavaScript文本的形式传送，因为任何人都可能截获该文本。

那么这一切是如何与WebRTC一起工作的？

getUserMedia方法需要通过Chrome浏览器访问摄像头和麦克风。由于HTML页面必须通过HTTPS传输到浏览器，这也意味着从该页面与您通信的任何服务器也必须是安全的。当涉及实时流时，HTTPS只是用来访问网站。实际的流传输将通过基于UDP的WebRTC连接完成。

WebRTC连接是通过WebSockets建立的，WebSockets与getUserMedia方法属于相同的安全标准。在WebSockets上执行SSL的方式是通过WSS。

最后S代表安全。对于HTTP流量，同样的证书和域可以用与WebSocket通信完全相同的方式使用。

更详细地发送信号

信令用于在浏览器和服务器之间建立连接，以实现视频/音频的发送和接收。根据设计，WebRTC是点对点得对等协议。

在进行信令阶段时，服务器和浏览器开始来回交换数据，以建立连接，该连接最终将推送和接收流式视频和音频。交换的信令数据有两种类型：SDP和ICE。

SDP - 涵盖媒体功能的会话控制消息

ICE candidates - 详细说明如何通过NAT连接的消息

SDP交换

涵盖媒体功能的会话控制消息

会话描述协议（称为SDP）是一种用于描述具有媒体功能的设备的功能的格式。这篇文章不是重新讨论WebRTC信令和SDP交换的主题，而是将重点放在安全性上，并简化了这里发生的事情。本质上，浏览器向服务器发送一个其功能列表，如它可以产生的分辨率、它支持的编解码器，以及其他用于设置流的详细信息。另一个对等节点以其可以处理的内容进行响应。在Red5Pro的例子中，它希望客户端使用H.264进行广播，以简化性能，因为它最大限度地减少了跨多个平台和服务的代码转换。一旦服务器和浏览器就如何通信达成一致意见，流程将进入ICE候选阶段。

ICE 候选阶段

用于进行P2P连接的网络配置细节

交换ICE candidates是与服务器建立P2P连接的另一个方面。ICE是一种协议，用于在internet上的设备之间建立连接。ICE candidates中包含的信息涉及是否使用TCP或UDP进行传输、客户端的IP地址以及与对等机直接连接的其他细节。

ICE还包含两个子协议，称为STUN（用于NAT的会话遍历实用程序）和TURN（用于在NAT周围使用中继的遍历）。STUN用于打穿防火墙/ NAT，如果无法使用STUN建立直接P2P，则使用TURN。TURN基本上通过（一个称为）TURN服务器的中间服务器路由通信。某些媒体服务器（就像Internet上的所有服务器一样）不使用防火墙。因此，通常可以减轻通过TURN服务器路由的需要。但是，肯定需要使用STUN服务器，因为世界上许多计算机/设备都设置了防火墙。

如上所述，WebRTC规范强制对所有流量进行加密。它通过DTLS和SRTP进行加密。

DTLS

视频和音频通道需要加密，这个过程从DTLS(数据报传输层安全)开始。为了深入了解这些古怪的细节，DTLS是TLS的一个子集，但经过修改后可以用于UDP连接。P2P连接两边的两个对等点都需要有用来加密和解密数据的密钥。所以需要交换这些钥匙。DTL在两个对等端交换用于加密和解密流的第一个密钥。然后浏览器就可以开始通过SRTP传输视频和音频。

SRTP

SRTP（安全实时协议）是WebRTC用于发送和接收加密的视频和音频的传输协议。SRTP工作方式的一部分是使用中的加密密钥会定期更改。因此，DTLS需要根据需要进行更新，并将通过SRTP进行更新。两种协议紧密协作，以确保整个会话中的流安全，因此通常将它们一起称为DTLS / SRTP。

需要注意的一件事：这里的主要焦点是描述连接到服务器对等方的广播客户端的对等方连接，即点对点的连接。

最后

如本文所述，WebRTC会通过自动配置来建立安全连接，以便在P2P连接上传输加密数据。WebRTC安全架构可以跨多种云平台在多个区域实现，包括同时的跨云解决方案。这些内在的特性使WebRTC成为安全流的良好选择，而不需要实现昂贵的第三方解决方案或耗时的内部解决方案。