為什么有些人認(rèn)為WebRTC是危險(xiǎn)的，主要?dú)w結(jié)為以下幾個(gè)方面

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

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

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

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

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

　　WebRTC通過(guò)簡(jiǎn)單的手段來(lái)阻止上述危險(xiǎn)發(fā)生，就是要求用戶必須明確地對(duì)攝像頭和麥克風(fēng)（兩者都可以單獨(dú)進(jìn)行）的使用進(jìn)行授權(quán)�？梢栽儐�(wèn)用戶是僅本次同意，還是永久性同意。WebRTC應(yīng)用不可能隨意獲取權(quán)限或者操作任意一個(gè)設(shè)備。另外，當(dāng)麥克風(fēng)或者攝像頭正在被使用的時(shí)候，用戶UI需要明確地顯示出麥克風(fēng)或者攝像頭正在工作。在Chrome中，在使用用戶媒體設(shè)備的標(biāo)簽頁(yè)上會(huì)有明確地標(biāo)識(shí)。

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

　　作為一項(xiàng)額外的規(guī)定，WebRTC標(biāo)準(zhǔn)規(guī)定了瀏覽器應(yīng)該在UI被覆蓋（也就是此窗口被其他窗口覆蓋）的時(shí)候，停止使用攝像頭和麥克風(fēng)。盡管這是一個(gè)理想的情況，但是這點(diǎn)并沒(méi)有必要保證，有些情況下，這項(xiàng)額外的功能很有可能并不是用戶想要得到的。

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

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

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

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

　　沒(méi)有辦法在不通過(guò)HTTPS提供的網(wǎng)站中使用WebRTC。這意味著WebRTC將強(qiáng)制開發(fā)人員使用安全連接進(jìn)行信號(hào)傳遞。這在使用iframe時(shí)，也是一樣的。

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

　　對(duì)我來(lái)說(shuō)，我寧愿依賴瀏覽器中的安全措施。因?yàn)�，這些經(jīng)歷了很多人的審查，他們都樂(lè)意宣布這些安全漏洞。但很多供應(yīng)商的軟件就不好說(shuō)了。

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

　　除了以上三個(gè)普遍被擔(dān)憂的安全問(wèn)題外，WebRTC還在更多方面，避免了危險(xiǎn)。

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

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

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

　　因?yàn)槭怯刹煌�的公司�?dú)立進(jìn)行開發(fā)的，所以每個(gè)IdP的實(shí)現(xiàn)之間都會(huì)不同，但是基礎(chǔ)的方法和功能都是基本一樣的。IdP不會(huì)給信令服務(wù)器提供身份驗(yàn)證；但是，他們會(huì)給用戶（以及他們的瀏覽器）提供驗(yàn)證。WebRTC也不會(huì)要求使用哪項(xiàng)服務(wù)，而這是基于網(wǎng)頁(yè)應(yīng)用的實(shí)現(xiàn)使用的。

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

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

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

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

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

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

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

　　由于信令協(xié)議并沒(méi)包括在WebRTC規(guī)范中，加密機(jī)制很明顯的依賴所選的信令協(xié)議。因?yàn)樾帕畎踩�性的相�?duì)開放屬性，本文將要專注于對(duì)SIP進(jìn)行簡(jiǎn)單的解釋。

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

　　因?yàn)镾IP是通過(guò)純文本發(fā)送的，對(duì)于攻擊者要想竊取到SIP消息真的是唾手可得。接下來(lái)就有可能竊取到消息所攜帶的信息，或者消息的報(bào)頭。如果攻擊者竊取到了邀請(qǐng)消息，他們就有可能把報(bào)頭的源地址改為他們自己的IP地址。

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

　　在建立通話的過(guò)程中，用戶瀏覽器使用中心注冊(cè)表進(jìn)行注冊(cè)。傳統(tǒng)VoIP必需這個(gè)注冊(cè)過(guò)程來(lái)定位和連接遠(yuǎn)端參與方。

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

　　最初的瀏覽器注冊(cè)是用于聲明用戶在連接中的地點(diǎn)，并且表明用戶的設(shè)備是否接受通話請(qǐng)求。但是，這個(gè)過(guò)程會(huì)給不良的人進(jìn)行“注冊(cè)劫持”的攻擊機(jī)會(huì)。

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

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

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

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

　　這類攻擊可以使用SIPS（SIP over TLS）以及驗(yàn)證SIP請(qǐng)求和回復(fù)消息來(lái)進(jìn)行抑制。事實(shí)上，使用SIPS和回復(fù)認(rèn)證可以抑制很多包括竊聽和假扮用戶在內(nèi)的攻擊。

　　MiTM攻擊

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

　　不法方可以將捕捉到的數(shù)據(jù)包重放給服務(wù)器，造成服務(wù)器給原本的目的地?fù)艽螂娫�。換句話說(shuō)，這會(huì)采取第二個(gè)來(lái)路不明的通話請(qǐng)求，而這個(gè)請(qǐng)求與對(duì)等端已經(jīng)接收到的請(qǐng)求完全一樣。雖然這是一件很煩人的事情，但是攻擊者并不會(huì)成為通話的一方，因?yàn)樗麄兊腎P信息沒(méi)有包含在信令數(shù)據(jù)包中。

　　網(wǎng)頁(yè)服務(wù)器并沒(méi)有每個(gè)獨(dú)立會(huì)話請(qǐng)求的狀態(tài)。雖然說(shuō)有驗(yàn)證的Cookies，但是這也只不過(guò)是一個(gè)有著會(huì)話ID的數(shù)據(jù)文件。這些cookies通過(guò)最初的連入權(quán)限由網(wǎng)頁(yè)服務(wù)器發(fā)送給瀏覽器。

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

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

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

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

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

　　為了達(dá)到這兩點(diǎn)，電信供應(yīng)商必須努力嘗試所有可能性，來(lái)保護(hù)消費(fèi)者不會(huì)因?yàn)樗麄冏陨淼腻e(cuò)誤而暴露自己的系統(tǒng)。

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

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

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

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

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

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

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

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