為什么有些人認為WebRTC是危險的，主要歸結為以下幾個方面

　　傳統(tǒng)電腦版軟件中的一個普遍問題是可否對應用本身產(chǎn)生信用。在安裝新軟件或新插件時，常常會在不知情的情況下被安裝了附帶的惡意軟件或者本身并不想安裝的垃圾軟件。很多終端用戶并不知道這些軟件是怎么來的。惡意的第三方特別擅長用安全且授信的軟件來包裝自己的惡意軟件，并且在免費的軟件網(wǎng)站上提供他們的用戶包。

　　但是WebRTC不需要安裝任何形式的插件和其他內(nèi)容。所有基本的WebRTC技術都已經(jīng)作為瀏覽器的一部分被內(nèi)置其中。用戶可以在不進行提前設置或者準備的情況下就隨時瀏覽或者使用任意一個WebRTC應用。所以只要使用的是合適的WebRTC應用，就不用擔心會不小心安裝什么惡意軟件或者病毒了。

　　另外一個相關的考慮是給已經(jīng)發(fā)現(xiàn)的軟件漏洞打補丁。就像任何一項軟件技術一樣，WebRTC在未來的使用過程中也一定會發(fā)現(xiàn)bug和易受攻擊漏洞。如果發(fā)現(xiàn)了一個傳統(tǒng)電腦軟件中的易受攻擊漏洞，開發(fā)針對此漏洞的補丁可能會花費掉一定的時間。這是應用開發(fā)中的一個常見問題，安全是僅次于功能以外最棘手的問題。

　　瀏覽器由于用戶上報問題的高頻率和大范圍，以及其本身存在的特性，一直處于一個高速開發(fā)狀態(tài)中。因為WebRTC的內(nèi)容是作為瀏覽器的一部分所提供的，它很可能經(jīng)常會在瀏覽器升級的同時獲得升級。一旦發(fā)現(xiàn)了一個WebRTC瀏覽器實現(xiàn)中的易受攻擊漏洞，那么很有可能會立即對其開展修復工作。實際情況我們也可以從Chrome和Firefox緊密的開發(fā)周期中驗證上述說法。事實上，在自動更新周期中，WebRTC內(nèi)容能夠一旦補丁在服務器上可用的同時，就通過新版本的瀏覽器得到更新�，F(xiàn)在絕大多數(shù)的瀏覽器都有著在發(fā)現(xiàn)嚴重安全漏洞的24小時自動更新的良好記錄。

　　瀏覽器可以接入本地資源（包括攝像頭，麥克，文件），然而也就不可避免的引發(fā)對網(wǎng)頁激活用戶麥克風和攝像頭的擔憂。如果網(wǎng)頁應用可以隨意獲取用戶攝像頭和麥克風的使用權限，那么不良的軟件可能就會在用戶不知情的情況下打開攝像頭和麥克風進行錄像錄音。

　　WebRTC通過簡單的手段來阻止上述危險發(fā)生，就是要求用戶必須明確地對攝像頭和麥克風（兩者都可以單獨進行）的使用進行授權�？梢栽儐栍脩羰莾H本次同意，還是永久性同意。WebRTC應用不可能隨意獲取權限或者操作任意一個設備。另外，當麥克風或者攝像頭正在被使用的時候，用戶UI需要明確地顯示出麥克風或者攝像頭正在工作。在Chrome中，在使用用戶媒體設備的標簽頁上會有明確地標識。

　　這項安全保護的理念是用戶每次都需要自己進行決定是否允許撥打通話或者接聽通話。換句話說，用戶必須明白：— 誰或者什么正在請求獲取我媒體設備的權限？— 媒體流是傳輸?shù)侥模?mdash; 或者二者都需明白。

　　作為一項額外的規(guī)定，WebRTC標準規(guī)定了瀏覽器應該在UI被覆蓋（也就是此窗口被其他窗口覆蓋）的時候，停止使用攝像頭和麥克風。盡管這是一個理想的情況，但是這點并沒有必要保證，有些情況下，這項額外的功能很有可能并不是用戶想要得到的。

　　屏幕分享帶來了對安全性更深的思考。用戶可能不會立即意識到他們所共享的范圍到底有多大。事實上，他們常常會認為他們只是在與他人共享一個特定的窗口，但是他們其實是在給其他人共享整個屏幕。上述過程是用戶錯誤的設定屏幕共享設置而造成的，或者也有可能是用戶在使用中忘了他們分享的范圍是什么了。

　　有各種不同的做法會讓實時通信軟件暴露在安全隱患中。其中需要特別值得注意的是在信息傳輸?shù)倪^程中截取未加密的媒體或者數(shù)據(jù)。這可以發(fā)生在瀏覽器到瀏覽器之間或者瀏覽器到服務器之間的通信過程中，第三方可以竊取到所有發(fā)送的數(shù)據(jù)。但是在數(shù)據(jù)加密之后，可以有效的組織竊聽者獲取通信流中的內(nèi)容。只有擁有加密密鑰的會話參與方才可以將通信數(shù)據(jù)流解碼。

　　很多人質(zhì)疑的一件事是為什么WebRTC總是加密的。其實，加密功能在WebRTC中是強制要求的，所有內(nèi)容，包括信令機制，都必須進行加密工作。

　　一切都是加密的。在其他VoIP解決方案中，開發(fā)人員可以配置加密開啟和關閉

　　沒有辦法在不通過HTTPS提供的網(wǎng)站中使用WebRTC。這意味著WebRTC將強制開發(fā)人員使用安全連接進行信號傳遞。這在使用iframe時，也是一樣的。

　　用戶被要求允許訪問其媒體輸入。每個瀏覽器的處理都會略微不同，這些模型也會隨著時間的推移而改變，但是足以說明這里的想法，是為了平衡用戶的隱私和服務的可用性。

　　對我來說，我寧愿依賴瀏覽器中的安全措施。因為，這些經(jīng)歷了很多人的審查，他們都樂意宣布這些安全漏洞。但很多供應商的軟件就不好說了。

　　·····························

　　除了以上三個普遍被擔憂的安全問題外，WebRTC還在更多方面，避免了危險。

　　我們希望用戶能夠識別他們對等端的身份信息，也就是用戶很自然的想要確認他們正在溝通的人就是他們想要進行交流的那個人，而不是某個冒名頂替的騙子。

　　盡管信令服務器可以為用戶身份聲明起到某些方面的作用，但信令服務器本身卻不是被信任的。我們需要將對等端驗證的工作與信令服務器相獨立出來。這可以通過使用身份提供者來實現(xiàn)。

　　最近有很多基于網(wǎng)絡的身份提供者（IdP）在網(wǎng)上變得很常見，包括Facebook Connect，BrowerID（Mozilla提供），OAuth（Twitter提供）。這些機制的目的很簡單，就是以身份驗證提供者本身的權力在其他服務器/用戶那里對你的身份信息進行驗證。如果有一個用戶有一個Facebook賬戶，那么他就能使用Facebook Connect來向其他用戶證明，他就是他在Facebook上聲稱自己是的那個人。這使用戶可以將他們在其他服務上的驗證信息，與他們已授信服務上的主要賬戶相捆綁。注意這種情況中，身份提供者所掌控的“信任”等級對終端用戶或者服務來說是主觀的，并且通常是與用戶在互聯(lián)網(wǎng)上的聲譽所緊緊捆綁的。

　　因為是由不同的公司獨立進行開發(fā)的，所以每個IdP的實現(xiàn)之間都會不同，但是基礎的方法和功能都是基本一樣的。IdP不會給信令服務器提供身份驗證；但是，他們會給用戶（以及他們的瀏覽器）提供驗證。WebRTC也不會要求使用哪項服務，而這是基于網(wǎng)頁應用的實現(xiàn)使用的。

　　因為網(wǎng)頁應用（通話發(fā)起端）與驗證過程無關，瀏覽器能夠安全的產(chǎn)生驗證處理過程的輸入內(nèi)容，以及安全地在網(wǎng)頁應用上顯示輸出內(nèi)容，是很重要的一點。這個過程決不能被應用進行篡改和誤傳。

　　使用ICE的一個不好的地方是一個對等端可以獲取到另一方的IP地址。由于IP地址是全球公共注冊的，他們就可以根據(jù)IP地址獲取例如對等端所處位置的細節(jié)信息。當然這對對等端用戶來說是不利的，所以他們想要避免這件事情的發(fā)生。

　　WebRTC最初的設計目的并不是用于防止用戶的信息被不良網(wǎng)站所竊取。通常，這些惡意網(wǎng)站會從任何HTTP事務中獲得用戶的信息，至少會得到用戶服務器的反射地址。想要將IP地址隱藏起來對服務器不可見的話，需要有其他特定的機制，在本文中不會進行論述。

　　WebRTC具有很多機制，可以使網(wǎng)頁應用于用戶一起將用戶的IP地址隱藏起來，對會話的另一方不可見。接下來將要對這些機制進行詳細的描述。

　　WebRTC實現(xiàn)要求提供一項機制，讓JS抑制著ICE協(xié)商，直到用戶決定接聽來電為止。這項規(guī)定協(xié)助終端用戶在拒絕接聽通話的時候阻止對方獲取自己的IP地址。

　　第二個這種規(guī)定是任何實現(xiàn)都必須提供一個機制，發(fā)起通話的app的Java需要知名只用TURN候選項才能被使用。這可以防止對方獲取用戶的IP地址。

　　另外，還有一個機制要求通話發(fā)起方軟件要重新配置現(xiàn)有通話來加入一個非TURN候選項。與上文所寫的兩個機制一同，使ICE協(xié)商能夠在撥入通話提示的時候立即建立起來，這樣可以降低延時，也會避免在用戶決定接聽以前就公開用戶的IP地址。這就令用戶可以在通話的過程中完全隱藏自己的IP地址。

　　由于信令協(xié)議并沒包括在WebRTC規(guī)范中，加密機制很明顯的依賴所選的信令協(xié)議。因為信令安全性的相對開放屬性，本文將要專注于對SIP進行簡單的解釋。

　　SIP是VoIP通信中廣泛使用的標準，來設立和結束通話。但是，SIP是由HTTP和SMTP所衍生來的—這兩個協(xié)議都是規(guī)范開發(fā)的。因為它使用明文消息進行信息交換，所以就很容易被不懷好意的人竊取SIP消息。如果攻擊者能夠看到用戶的敏感信息，他們就可以用這些信息來敲詐用戶。并且如果攻擊者能夠獲取連入操作網(wǎng)絡的權限，他甚至都有可能破解出WebRTC通信中的核心內(nèi)容。

　　因為SIP是通過純文本發(fā)送的，對于攻擊者要想竊取到SIP消息真的是唾手可得。接下來就有可能竊取到消息所攜帶的信息，或者消息的報頭。如果攻擊者竊取到了邀請消息，他們就有可能把報頭的源地址改為他們自己的IP地址。

　　SIP是一項針對信令和控制多媒體通信會話的通信協(xié)議，經(jīng)常應用于VoIP技術，用來建立和結束通話。同樣也可以應用于WebRTC實現(xiàn)中的信令目的。但是SIP消息通常是以未經(jīng)加密的純文本類型發(fā)送的。會引起各種潛在的攻擊危險，我們會針對這一方面進行進一步的測試。

　　在建立通話的過程中，用戶瀏覽器使用中心注冊表進行注冊。傳統(tǒng)VoIP必需這個注冊過程來定位和連接遠端參與方。

　　當一端（Bob）想要建立一則通話的時候，他通過中央代理服務器（信令服務器）發(fā)送邀請消息。服務器負責傳輸這類消息，以及提供定位另一端用戶的方法。服務器想要在查詢過程中嘗試一系列的方法（例如DNS）來定位終端用戶。

　　最初的瀏覽器注冊是用于聲明用戶在連接中的地點，并且表明用戶的設備是否接受通話請求。但是，這個過程會給不良的人進行“注冊劫持”的攻擊機會。

　　在注冊消息的交換中包括了“接觸：”一項，其中有用戶的IP地址。不管什么時候信令服務器處理一則撥入通話，用戶名稱（或者電話號碼）都與注冊的IP地址相匹配，并且根據(jù)此IP將邀請消息進行傳遞。這些注冊信息是定期更新的，確�，F(xiàn)存的記錄時刻保持是最新的。

　　因為SIP消息總是由明文發(fā)送的，攻擊者很輕易的就能截取并督導這些注冊消息中的內(nèi)容。在竊取到SIP消息之后，可以使用合適的工具（比如SiVuS消息生成器）來聲稱一個類似的SIP信息，但是在這個假消息中，用戶真正的IP地址被替代為攻擊者自身的IP地址。攻擊者之后只要將實際的用戶屏蔽掉，然后周期地發(fā)送這類信息，就可以把所有撥入的通話轉(zhuǎn)到他們自己那里。

　　有很多的方法可以使攻擊者將合法用戶禁用掉，包括：— 進行針對用戶設備的DOS攻擊 — 將用戶去注冊（另一種攻擊方法，在本文不會提到）— 開啟一場注冊競爭，攻擊者快速（每15秒）且反復地發(fā)送注冊請求，這樣就會覆蓋掉合法用戶的注冊請求。這都是WebRTC信令服務的潛在危險。

　　因為SIP的實現(xiàn)不支持對消息內(nèi)容完整性的檢查，所以更改和重放類型的攻擊不會被探測到。即便是服務器要求對用戶注冊進行驗證的話也會遭到攻擊，因為攻擊者一旦捕獲了消息的話，就可以任意對消息進行更改和回放了。

　　這類攻擊可以使用SIPS（SIP over TLS）以及驗證SIP請求和回復消息來進行抑制。事實上，使用SIPS和回復認證可以抑制很多包括竊聽和假扮用戶在內(nèi)的攻擊。

　　MiTM攻擊

　　如果攻擊者能夠竊取到最初的SIP消息，他就可能會進行MiTM攻擊。

　　不法方可以將捕捉到的數(shù)據(jù)包重放給服務器，造成服務器給原本的目的地撥打電話。換句話說，這會采取第二個來路不明的通話請求，而這個請求與對等端已經(jīng)接收到的請求完全一樣。雖然這是一件很煩人的事情，但是攻擊者并不會成為通話的一方，因為他們的IP信息沒有包含在信令數(shù)據(jù)包中。

　　網(wǎng)頁服務器并沒有每個獨立會話請求的狀態(tài)。雖然說有驗證的Cookies，但是這也只不過是一個有著會話ID的數(shù)據(jù)文件。這些cookies通過最初的連入權限由網(wǎng)頁服務器發(fā)送給瀏覽器。

　　如果cookie被竊取到了并且被復制，它可能會讓竊取者獲得正在進行會話的完整權限。為了嘗試避免此種危險發(fā)生，大多數(shù)的網(wǎng)站都會使用涉及到用戶IP地址和時間戳的算法來生成cookie來產(chǎn)生一個唯一的身份ID。

　　盡管信令看起來可以提供一些很誘人的有點，但是它會成為攻擊者的攻擊對象。另外對于媒體流來說，信令層也可以被加密。其中一個加密方法是OnSIP，使用Secure WebSocket上的SIP（wss://而不是ws://），使用由TLS加密的WebSocket連接。

　　盡管這不在本文的范疇之內(nèi)，但是還要簡單的寫一寫，其他信令技術與其類似，可以通過使用TLS來對其WebSocket或者其他網(wǎng)絡傳輸進行加密。與所有加密過程相同，只要第三方不知道加密的密鑰，他們就無法讀懂通信所傳輸?shù)膬?nèi)容。這會有助于抵擋上文所述的攻擊危險，但是需要強調(diào)的是，應用程序員必須明確地實現(xiàn)被加密的信令方法，這個功能才有用。

　　通過給WebRTC提供支持，一個電信網(wǎng)絡不應該被暴露在安全隱患中。但是，用戶手中的設備和軟件會不可避免的可能受到不法人員的攻擊。

　　因此，所有從未信任源（也就是消費者/用戶）接收的數(shù)據(jù)必須要經(jīng)過驗證，電信網(wǎng)絡必須認為任何發(fā)送給用戶的數(shù)據(jù)都有可能被心懷惡意的人竊取。

　　為了達到這兩點，電信供應商必須努力嘗試所有可能性，來保護消費者不會因為他們自身的錯誤而暴露自己的系統(tǒng)。

　　跨站腳本（Cross-site ing）是網(wǎng)頁應用中一個典型的易受攻擊點。它可以使攻擊者侵入網(wǎng)頁的客戶端腳本。跨站腳本的弱點可能被攻擊者利用，來繞開像來源規(guī)則一樣的連入控制。

　　跨站腳本的影響可能微不足道，也有可能造成嚴重的安全隱患，要看網(wǎng)站所處理數(shù)據(jù)的敏感度以及網(wǎng)站所有者是否用了任何能夠抑制安全性的東西。

　　因為訪問WebRTC應用的主要方法是使用可運行HTML5的瀏覽器，所以有一些特定的安全性考慮比如；保護密鑰和敏感信息免受跨站腳本或掛域名的攻擊，WebSocket的使用，iframe的安全性，以及其他問題。因為客戶端軟件是由用戶自己所控制的，絕大多數(shù)情況不由瀏覽器所控，所以WebRTC的用戶需要盡可能的在安全受保護的環(huán)境下使用軟件。如果不是的話，用戶所發(fā)送的所有數(shù)據(jù)都會暴露。

　　在現(xiàn)在這個智能手機和移動設備廣泛使用的時代。加密技術在近些年成為了一個很大的話題，也有很多大公司被竊聽以及政府大范圍電信竊聽的丑聞傳出。這導致了用戶對這些公司或組織的不信任度迅速上升，并且要求安全性方面要有很大的提高。所有終端用戶都想要知道他們的個人數(shù)據(jù)是否處于可控的私密范圍內(nèi)。

　　在安全性領域，WebRTC要遠優(yōu)于大多數(shù)VoIP服務。知道現(xiàn)在，很多服務通常都將安全性視為可有可沒有的性能，意味著大多數(shù)終端用戶使用VoIP的通話都沒有被加密。通常大公司是這件事請的始作俑者，為了節(jié)省預算而不考慮他們所處理的用戶數(shù)據(jù)的價值。但是因為WebRTC禁止未經(jīng)加密的通信建立，用戶可以放心他們的數(shù)據(jù)都是安全且私密的。

　　最初設計WebRTC時，安全性就是設計的目標之一，所以WebRTC強迫或者鼓勵在所有主要部分中使用重要的安全性理念。同樣因此，與簡單的內(nèi)置安全性一樣，WebRTC也鼓勵它的開發(fā)者嚴肅看待他們的安全性問題。

　　作為著重關注安全通信的結果，WebRTC目前被視為最安全的VoIP方案之一。默認進行加密的主要前提是通話在所有時候都是私密的。安全和加密不再被視為可選特性。并且WebRTC對于所有人來說都是免費的，給開發(fā)者提供了一個誘人的可靠的框架，用來搭建他們的下一個應用。

　　在不遠的將來，我們可以期待看到越來越多的通信服務都可以給他們的用戶提供大程度提高的安全保證。但是現(xiàn)在，WebRTC是這方面的領軍者。