正文字?jǐn)?shù)：2955 ?閱讀時長：4分鐘

WebRTC不僅僅是為低延遲實時流媒體傳輸而設(shè)計的。為了滿足現(xiàn)代流媒體應(yīng)用程序的需求，WebRTC還提供了流安全性。本文主要研究WebRTC的安全體系結(jié)構(gòu)以及如何設(shè)置它。

Written By?Red5Pro

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

數(shù)據(jù)加密

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

加密是一種對數(shù)據(jù)進(jìn)行處理的方式，以便只有授權(quán)方才能理解該信息。用技術(shù)術(shù)語來說，它是將明文轉(zhuǎn)換成密文的過程。簡單地說，加密獲取可讀數(shù)據(jù)并對其進(jìn)行修改，使其看起來是隨機的。這個過程中需要使用兩個加密密鑰。一個公共密鑰和一個私有密鑰。這些密鑰是加密消息的發(fā)送者和接收者都可以解密的一組數(shù)學(xué)值。加密需要是隨機的，以防止未經(jīng)授權(quán)的用戶訪問數(shù)據(jù)，以防止未經(jīng)授權(quán)的用戶訪問數(shù)據(jù)，但對于接收信息的授權(quán)方來說是可預(yù)測的，以便正確使用。

由于WebRTC直接在瀏覽器中工作，這意味著加密過程也可以在瀏覽器中執(zhí)行，而無需其他配置。此外，WebRTC不需要下載任何其他插件。這進(jìn)一步提高了安全性，因為它消除了第三方軟件帶來得影響以及諸如數(shù)據(jù)跟蹤或病毒之類的潛在副作用得擔(dān)憂。插件也是另一個潛在的安全風(fēng)險，因為它們是可以利用的附加連接。

WebRTC安全性實現(xiàn)了基于AES（高級加密標(biāo)準(zhǔn)）的保護(hù)。這樣，就消除了使用第三方或利用DIY平臺來管理與身份驗證設(shè)備和授權(quán)用戶相關(guān)的所有功能的風(fēng)險。相反，WebRTC使用視頻傳輸協(xié)議SRTP（安全實時協(xié)議）通過WebRTC專門用于視頻，音頻和數(shù)據(jù)的三個通道來發(fā)送和接收加密內(nèi)容。

SRTP用于加密和解密內(nèi)容的密鑰的交換是通過IETF的TLS版本（稱為DTLS（數(shù)據(jù)報傳輸層安全性Datagram Transport Layer Security））進(jìn)行管理的，該版本與UDP（用戶數(shù)據(jù)報協(xié)議）連接一起使用，UDP是WebRTC采用的超低延遲包傳輸協(xié)議。盡管我們描述使用UDP是因為這是使用WebRTC的典型設(shè)置，但應(yīng)注意的是，同樣的過程也可以通過TCP來完成。所有這一切都會隨著WebRTC流的實例化而自動發(fā)生。稍后將更詳細(xì)地介紹這一點。

此外，無論使用那種托管服務(wù)提供商，都將復(fù)制相同的WebRTC安全體系結(jié)構(gòu)。支持跨云解決方案的能力提高了靈活性。由于WebRTC安全實施是標(biāo)準(zhǔn)的，因此它還可以在不同區(qū)域中建立相同的安全功能特性。

加密可確保無法讀取廣播者和訂戶之間發(fā)送的數(shù)據(jù)。接下來的部分將首先介紹如何建立連接。

信號和CORS

CORS（cross-origin resource sharing跨資源網(wǎng)絡(luò)共享）可防止不必要的信息在網(wǎng)站和其他資源（如服務(wù)器、數(shù)據(jù)中心或其他網(wǎng)站）之間交換。這是一個W3C標(biāo)準(zhǔn)，它提供了一個過程，在這個過程中，服務(wù)器和網(wǎng)站可以交互，以確定允許通過跨源請求傳輸數(shù)據(jù)是否安全。

CORS也會影響WebRTC在實時流媒體中的使用。具體地說，關(guān)于在廣播機或訂閱客戶端與相應(yīng)的服務(wù)器之間建立連接，該服務(wù)器將充當(dāng)兩者之間的中繼點，用WebRTC的說法稱為“信令”。

為了讓一個流連接到另一個對等端，它們需要知道在哪里可以找到彼此。如果連接的兩端不在同一個web服務(wù)器上提供服務(wù)，CORS限制將阻止建立連接。在這種情況下，連接必須通過信令協(xié)議進(jìn)行協(xié)商。WebRTC規(guī)范沒有指定如何發(fā)送這些信令消息，因此可以通過HTTP或WebSockets發(fā)送。無論哪種方式，連接到服務(wù)器進(jìn)行信號發(fā)送，都需要處理CORS及其提供的配置。Red5Pro用WebSockets實現(xiàn)信令。在我們的Red5Pro自動縮放集群中，流管理器（Stream Manager）充當(dāng)信令服務(wù)器，將調(diào)用向下代理到邊緣和源節(jié)點，以建立從WebRTC客戶端到這些服務(wù)器節(jié)點的連接。下圖顯示了此關(guān)系以及將WebRTC發(fā)布服務(wù)器客戶端連接到源節(jié)點的流管理器。

HTTPS和安全WebSockets (WSS)

要從瀏覽器創(chuàng)建視頻，瀏覽器必須能夠訪問攝像機和麥克風(fēng)。在Chrome中，這是通過getUserMedia方法實現(xiàn)的，只有在安全網(wǎng)站上提供服務(wù)時，才能訪問該方法。由于HTML頁面必須通過HTTPS傳輸?shù)綖g覽器，這也意味著從該頁面與您通信的任何服務(wù)器也必須是安全的。

通過HTTPS傳輸站點內(nèi)容有兩個要求：1）訪問站點的域名，2）web服務(wù)器上安裝的已驗證提供商提供的證書。使用域名，瀏覽器根據(jù)它信任的提供程序所提供的證書驗證域。驗證后，將在瀏覽器和服務(wù)器之間執(zhí)行密鑰交換，以允許SSL加密。一旦加密，頁面將不會以純HTML/JavaScript文本的形式傳送，因為任何人都可能截獲該文本。

那么這一切是如何與WebRTC一起工作的？

getUserMedia方法需要通過Chrome瀏覽器訪問攝像頭和麥克風(fēng)。由于HTML頁面必須通過HTTPS傳輸?shù)綖g覽器，這也意味著從該頁面與您通信的任何服務(wù)器也必須是安全的。當(dāng)涉及實時流時，HTTPS只是用來訪問網(wǎng)站。實際的流傳輸將通過基于UDP的WebRTC連接完成。

WebRTC連接是通過WebSockets建立的，WebSockets與getUserMedia方法屬于相同的安全標(biāo)準(zhǔn)。在WebSockets上執(zhí)行SSL的方式是通過WSS。

最后S代表安全。對于HTTP流量，同樣的證書和域可以用與WebSocket通信完全相同的方式使用。

更詳細(xì)地發(fā)送信號

信令用于在瀏覽器和服務(wù)器之間建立連接，以實現(xiàn)視頻/音頻的發(fā)送和接收。根據(jù)設(shè)計，WebRTC是點對點得對等協(xié)議。

在進(jìn)行信令階段時，服務(wù)器和瀏覽器開始來回交換數(shù)據(jù)，以建立連接，該連接最終將推送和接收流式視頻和音頻。交換的信令數(shù)據(jù)有兩種類型：SDP和ICE。

SDP?- 涵蓋媒體功能的會話控制消息

ICE candidates?- 詳細(xì)說明如何通過NAT連接的消息

SDP交換

涵蓋媒體功能的會話控制消息

會話描述協(xié)議（稱為SDP）是一種用于描述具有媒體功能的設(shè)備的功能的格式。這篇文章不是重新討論WebRTC信令和SDP交換的主題，而是將重點放在安全性上，并簡化了這里發(fā)生的事情。本質(zhì)上，瀏覽器向服務(wù)器發(fā)送一個其功能列表，如它可以產(chǎn)生的分辨率、它支持的編解碼器，以及其他用于設(shè)置流的詳細(xì)信息。另一個對等節(jié)點以其可以處理的內(nèi)容進(jìn)行響應(yīng)。在Red5Pro的例子中，它希望客戶端使用H.264進(jìn)行廣播，以簡化性能，因為它最大限度地減少了跨多個平臺和服務(wù)的代碼轉(zhuǎn)換。一旦服務(wù)器和瀏覽器就如何通信達(dá)成一致意見，流程將進(jìn)入ICE候選階段。

ICE 候選階段

用于進(jìn)行P2P連接的網(wǎng)絡(luò)配置細(xì)節(jié)

交換ICE candidates是與服務(wù)器建立P2P連接的另一個方面。ICE是一種協(xié)議，用于在internet上的設(shè)備之間建立連接。ICE candidates中包含的信息涉及是否使用TCP或UDP進(jìn)行傳輸、客戶端的IP地址以及與對等機直接連接的其他細(xì)節(jié)。

ICE還包含兩個子協(xié)議，稱為STUN（用于NAT的會話遍歷實用程序）和TURN（用于在NAT周圍使用中繼的遍歷）。STUN用于打穿防火墻/ NAT，如果無法使用STUN建立直接P2P，則使用TURN。TURN基本上通過（一個稱為）TURN服務(wù)器的中間服務(wù)器路由通信。某些媒體服務(wù)器（就像Internet上的所有服務(wù)器一樣）不使用防火墻。因此，通常可以減輕通過TURN服務(wù)器路由的需要。但是，肯定需要使用STUN服務(wù)器，因為世界上許多計算機/設(shè)備都設(shè)置了防火墻。

如上所述，WebRTC規(guī)范強制對所有流量進(jìn)行加密。它通過DTLS和SRTP進(jìn)行加密。

DTLS

視頻和音頻通道需要加密，這個過程從DTLS(數(shù)據(jù)報傳輸層安全)開始。為了深入了解這些古怪的細(xì)節(jié)，DTLS是TLS的一個子集，但經(jīng)過修改后可以用于UDP連接。P2P連接兩邊的兩個對等點都需要有用來加密和解密數(shù)據(jù)的密鑰。所以需要交換這些鑰匙。DTL在兩個對等端交換用于加密和解密流的第一個密鑰。然后瀏覽器就可以開始通過SRTP傳輸視頻和音頻。

SRTP

SRTP（安全實時協(xié)議）是WebRTC用于發(fā)送和接收加密的視頻和音頻的傳輸協(xié)議。SRTP工作方式的一部分是使用中的加密密鑰會定期更改。因此，DTLS需要根據(jù)需要進(jìn)行更新，并將通過SRTP進(jìn)行更新。兩種協(xié)議緊密協(xié)作，以確保整個會話中的流安全，因此通常將它們一起稱為DTLS / SRTP。

需要注意的一件事：這里的主要焦點是描述連接到服務(wù)器對等方的廣播客戶端的對等方連接，即點對點的連接。

最后

如本文所述，WebRTC會通過自動配置來建立安全連接，以便在P2P連接上傳輸加密數(shù)據(jù)。WebRTC安全架構(gòu)可以跨多種云平臺在多個區(qū)域?qū)崿F(xiàn)，包括同時的跨云解決方案。這些內(nèi)在的特性使WebRTC成為安全流的良好選擇，而不需要實現(xiàn)昂貴的第三方解決方案或耗時的內(nèi)部解決方案。

灣區(qū)最原汁原味的技術(shù)，全球最前沿的應(yīng)用實踐

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

LiveVideoStackCon 2020?美國站

2020年12月10日-12月11日

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。