正文字數：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成為安全流的良好選擇，而不需要實現昂貴的第三方解決方案或耗時的內部解決方案。

灣區最原汁原味的技術，全球最前沿的應用實踐

無需漂洋過海，我們在線上等您！

LiveVideoStackCon 2020?美國站

2020年12月10日-12月11日

點擊【閱讀原文】了解更多詳細信息

總結

以上是生活随笔為你收集整理的WebRTC安全体系架构的8个组件的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。