WebRTC安全体系架构的8个组件
正文字?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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 使用iPhone相机和OpenCV来完成
- 下一篇: Wave-Share -无服务器,点对点