您当前的位置是:  首页 > 新闻 > 国内 >
 首页 > 新闻 > 国内 >

WebRTC 是否安全

2017-08-15 14:09:35   作者:   来源:搜狐IT   评论:0  点击:


  
  关于WebRTC是否安全的疑虑和讨论,总是无法停止。那么,它到底安不安全,本篇文章将从不同方面,完整但简要地分析下WebRTC的安全性。
  为什么有些人认为WebRTC是危险的,主要归结为以下几个方面
  • 恶意软件或病毒可能被安装在一个不起眼的插件或应用中
  • 应用可能会在用户不知情的情况下记录视频和其它信息
  • 未加密的媒体数据流可以会在浏览器或通信途中被获取
  • 但实际上,WebRTC通过各种特性避免了这些问题。
  1、软件或插件的安装与更新
  传统电脑版软件中的一个普遍问题是可否对应用本身产生信用。在安装新软件或新插件时,常常会在不知情的情况下被安装了附带的恶意软件或者本身并不想安装的垃圾软件。很多终端用户并不知道这些软件是怎么来的。恶意的第三方特别擅长用安全且授信的软件来包装自己的恶意软件,并且在免费的软件网站上提供他们的用户包。
  但是WebRTC不需要安装任何形式的插件和其他内容。所有基本的WebRTC技术都已经作为浏览器的一部分被内置其中。用户可以在不进行提前设置或者准备的情况下就随时浏览或者使用任意一个WebRTC应用。所以只要使用的是合适的WebRTC应用,就不用担心会不小心安装什么恶意软件或者病毒了。
  另外一个相关的考虑是给已经发现的软件漏洞打补丁。就像任何一项软件技术一样,WebRTC在未来的使用过程中也一定会发现bug和易受攻击漏洞。如果发现了一个传统电脑软件中的易受攻击漏洞,开发针对此漏洞的补丁可能会花费掉一定的时间。这是应用开发中的一个常见问题,安全是仅次于功能以外最棘手的问题。
  浏览器由于用户上报问题的高频率和大范围,以及其本身存在的特性,一直处于一个高速开发状态中。因为WebRTC的内容是作为浏览器的一部分所提供的,它很可能经常会在浏览器升级的同时获得升级。一旦发现了一个WebRTC浏览器实现中的易受攻击漏洞,那么很有可能会立即对其开展修复工作。实际情况我们也可以从Chrome和Firefox紧密的开发周期中验证上述说法。事实上,在自动更新周期中,WebRTC内容能够一旦补丁在服务器上可用的同时,就通过新版本的浏览器得到更新。现在绝大多数的浏览器都有着在发现严重安全漏洞的24小时自动更新的良好记录。
  2、接入媒体/本地资源
  浏览器可以接入本地资源(包括摄像头,麦克,文件),然而也就不可避免的引发对网页激活用户麦克风和摄像头的担忧。如果网页应用可以随意获取用户摄像头和麦克风的使用权限,那么不良的软件可能就会在用户不知情的情况下打开摄像头和麦克风进行录像录音。
  WebRTC通过简单的手段来阻止上述危险发生,就是要求用户必须明确地对摄像头和麦克风(两者都可以单独进行)的使用进行授权。可以询问用户是仅本次同意,还是永久性同意。WebRTC应用不可能随意获取权限或者操作任意一个设备。另外,当麦克风或者摄像头正在被使用的时候,用户UI需要明确地显示出麦克风或者摄像头正在工作。在Chrome中,在使用用户媒体设备的标签页上会有明确地标识。
  这项安全保护的理念是用户每次都需要自己进行决定是否允许拨打通话或者接听通话。换句话说,用户必须明白:— 谁或者什么正在请求获取我媒体设备的权限?— 媒体流是传输到哪?— 或者二者都需明白。
  作为一项额外的规定,WebRTC标准规定了浏览器应该在UI被覆盖(也就是此窗口被其他窗口覆盖)的时候,停止使用摄像头和麦克风。尽管这是一个理想的情况,但是这点并没有必要保证,有些情况下,这项额外的功能很有可能并不是用户想要得到的。
  屏幕分享带来了对安全性更深的思考。用户可能不会立即意识到他们所共享的范围到底有多大。事实上,他们常常会认为他们只是在与他人共享一个特定的窗口,但是他们其实是在给其他人共享整个屏幕。上述过程是用户错误的设定屏幕共享设置而造成的,或者也有可能是用户在使用中忘了他们分享的范围是什么了。
  3、媒体加密与通信安全
  有各种不同的做法会让实时通信软件暴露在安全隐患中。其中需要特别值得注意的是在信息传输的过程中截取未加密的媒体或者数据。这可以发生在浏览器到浏览器之间或者浏览器到服务器之间的通信过程中,第三方可以窃取到所有发送的数据。但是在数据加密之后,可以有效的组织窃听者获取通信流中的内容。只有拥有加密密钥的会话参与方才可以将通信数据流解码。
  很多人质疑的一件事是为什么WebRTC总是加密的。其实,加密功能在WebRTC中是强制要求的,所有内容,包括信令机制,都必须进行加密工作。
  一切都是加密的。在其他VoIP解决方案中,开发人员可以配置加密开启和关闭
  没有办法在不通过HTTPS提供的网站中使用WebRTC。这意味着WebRTC将强制开发人员使用安全连接进行信号传递。这在使用iframe时,也是一样的。
  用户被要求允许访问其媒体输入。每个浏览器的处理都会略微不同,这些模型也会随着时间的推移而改变,但是足以说明这里的想法,是为了平衡用户的隐私和服务的可用性。
  对我来说,我宁愿依赖浏览器中的安全措施。因为,这些经历了很多人的审查,他们都乐意宣布这些安全漏洞。但很多供应商的软件就不好说了。
  ·····························
  除了以上三个普遍被担忧的安全问题外,WebRTC还在更多方面,避免了危险。
  4、基于网络的对等端验证以及身份管理
  我们希望用户能够识别他们对等端的身份信息,也就是用户很自然的想要确认他们正在沟通的人就是他们想要进行交流的那个人,而不是某个冒名顶替的骗子。
  尽管信令服务器可以为用户身份声明起到某些方面的作用,但信令服务器本身却不是被信任的。我们需要将对等端验证的工作与信令服务器相独立出来。这可以通过使用身份提供者来实现。
  最近有很多基于网络的身份提供者(IdP)在网上变得很常见,包括Facebook Connect,BrowerID(Mozilla提供),OAuth(Twitter提供)。这些机制的目的很简单,就是以身份验证提供者本身的权力在其他服务器/用户那里对你的身份信息进行验证。如果有一个用户有一个Facebook账户,那么他就能使用Facebook Connect来向其他用户证明,他就是他在Facebook上声称自己是的那个人。这使用户可以将他们在其他服务上的验证信息,与他们已授信服务上的主要账户相捆绑。注意这种情况中,身份提供者所掌控的“信任”等级对终端用户或者服务来说是主观的,并且通常是与用户在互联网上的声誉所紧紧捆绑的。
  因为是由不同的公司独立进行开发的,所以每个IdP的实现之间都会不同,但是基础的方法和功能都是基本一样的。IdP不会给信令服务器提供身份验证;但是,他们会给用户(以及他们的浏览器)提供验证。WebRTC也不会要求使用哪项服务,而这是基于网页应用的实现使用的。
  因为网页应用(通话发起端)与验证过程无关,浏览器能够安全的产生验证处理过程的输入内容,以及安全地在网页应用上显示输出内容,是很重要的一点。这个过程决不能被应用进行篡改和误传。
  5、IP位置隐私性
  使用ICE的一个不好的地方是一个对等端可以获取到另一方的IP地址。由于IP地址是全球公共注册的,他们就可以根据IP地址获取例如对等端所处位置的细节信息。当然这对对等端用户来说是不利的,所以他们想要避免这件事情的发生。
  WebRTC最初的设计目的并不是用于防止用户的信息被不良网站所窃取。通常,这些恶意网站会从任何HTTP事务中获得用户的信息,至少会得到用户服务器的反射地址。想要将IP地址隐藏起来对服务器不可见的话,需要有其他特定的机制,在本文中不会进行论述。
  WebRTC具有很多机制,可以使网页应用于用户一起将用户的IP地址隐藏起来,对会话的另一方不可见。接下来将要对这些机制进行详细的描述。
  WebRTC实现要求提供一项机制,让JS抑制着ICE协商,直到用户决定接听来电为止。这项规定协助终端用户在拒绝接听通话的时候阻止对方获取自己的IP地址。
  第二个这种规定是任何实现都必须提供一个机制,发起通话的app的Java需要知名只用TURN候选项才能被使用。这可以防止对方获取用户的IP地址。
  另外,还有一个机制要求通话发起方软件要重新配置现有通话来加入一个非TURN候选项。与上文所写的两个机制一同,使ICE协商能够在拨入通话提示的时候立即建立起来,这样可以降低延时,也会避免在用户决定接听以前就公开用户的IP地址。这就令用户可以在通话的过程中完全隐藏自己的IP地址。
  6、信令层
  由于信令协议并没包括在WebRTC规范中,加密机制很明显的依赖所选的信令协议。因为信令安全性的相对开放属性,本文将要专注于对SIP进行简单的解释。
  SIP是VoIP通信中广泛使用的标准,来设立和结束通话。但是,SIP是由HTTP和SMTP所衍生来的—这两个协议都是规范开发的。因为它使用明文消息进行信息交换,所以就很容易被不怀好意的人窃取SIP消息。如果攻击者能够看到用户的敏感信息,他们就可以用这些信息来敲诈用户。并且如果攻击者能够获取连入操作网络的权限,他甚至都有可能破解出WebRTC通信中的核心内容。
  因为SIP是通过纯文本发送的,对于攻击者要想窃取到SIP消息真的是唾手可得。接下来就有可能窃取到消息所携带的信息,或者消息的报头。如果攻击者窃取到了邀请消息,他们就有可能把报头的源地址改为他们自己的IP地址。
  6.1、SIP缺陷
  SIP是一项针对信令和控制多媒体通信会话的通信协议,经常应用于VoIP技术,用来建立和结束通话。同样也可以应用于WebRTC实现中的信令目的。但是SIP消息通常是以未经加密的纯文本类型发送的。会引起各种潜在的攻击危险,我们会针对这一方面进行进一步的测试。
  SIP流
  在建立通话的过程中,用户浏览器使用中心注册表进行注册。传统VoIP必需这个注册过程来定位和连接远端参与方。
  当一端(Bob)想要建立一则通话的时候,他通过中央代理服务器(信令服务器)发送邀请消息。服务器负责传输这类消息,以及提供定位另一端用户的方法。服务器想要在查询过程中尝试一系列的方法(例如DNS)来定位终端用户。
  注册劫持
  最初的浏览器注册是用于声明用户在连接中的地点,并且表明用户的设备是否接受通话请求。但是,这个过程会给不良的人进行“注册劫持”的攻击机会。
  在注册消息的交换中包括了“接触:”一项,其中有用户的IP地址。不管什么时候信令服务器处理一则拨入通话,用户名称(或者电话号码)都与注册的IP地址相匹配,并且根据此IP将邀请消息进行传递。这些注册信息是定期更新的,确保现存的记录时刻保持是最新的。
  因为SIP消息总是由明文发送的,攻击者很轻易的就能截取并督导这些注册消息中的内容。在窃取到SIP消息之后,可以使用合适的工具(比如SiVuS消息生成器)来声称一个类似的SIP信息,但是在这个假消息中,用户真正的IP地址被替代为攻击者自身的IP地址。攻击者之后只要将实际的用户屏蔽掉,然后周期地发送这类信息,就可以把所有拨入的通话转到他们自己那里。
  有很多的方法可以使攻击者将合法用户禁用掉,包括:— 进行针对用户设备的DOS攻击 — 将用户去注册(另一种攻击方法,在本文不会提到)— 开启一场注册竞争,攻击者快速(每15秒)且反复地发送注册请求,这样就会覆盖掉合法用户的注册请求。这都是WebRTC信令服务的潜在危险。
  因为SIP的实现不支持对消息内容完整性的检查,所以更改和重放类型的攻击不会被探测到。即便是服务器要求对用户注册进行验证的话也会遭到攻击,因为攻击者一旦捕获了消息的话,就可以任意对消息进行更改和回放了。
  这类攻击可以使用SIPS(SIP over TLS)以及验证SIP请求和回复消息来进行抑制。事实上,使用SIPS和回复认证可以抑制很多包括窃听和假扮用户在内的攻击。
  其他可能的攻击
  MiTM攻击
  如果攻击者能够窃取到最初的SIP消息,他就可能会进行MiTM攻击。
  重放攻击
  不法方可以将捕捉到的数据包重放给服务器,造成服务器给原本的目的地拨打电话。换句话说,这会采取第二个来路不明的通话请求,而这个请求与对等端已经接收到的请求完全一样。虽然这是一件很烦人的事情,但是攻击者并不会成为通话的一方,因为他们的IP信息没有包含在信令数据包中。
  会话劫持
  网页服务器并没有每个独立会话请求的状态。虽然说有验证的Cookies,但是这也只不过是一个有着会话ID的数据文件。这些cookies通过最初的连入权限由网页服务器发送给浏览器。
  如果cookie被窃取到了并且被复制,它可能会让窃取者获得正在进行会话的完整权限。为了尝试避免此种危险发生,大多数的网站都会使用涉及到用户IP地址和时间戳的算法来生成cookie来产生一个唯一的身份ID。
  加密
  尽管信令看起来可以提供一些很诱人的有点,但是它会成为攻击者的攻击对象。另外对于媒体流来说,信令层也可以被加密。其中一个加密方法是OnSIP,使用Secure WebSocket上的SIP(wss://而不是ws://),使用由TLS加密的WebSocket连接。
  尽管这不在本文的范畴之内,但是还要简单的写一写,其他信令技术与其类似,可以通过使用TLS来对其WebSocket或者其他网络传输进行加密。与所有加密过程相同,只要第三方不知道加密的密钥,他们就无法读懂通信所传输的内容。这会有助于抵挡上文所述的攻击危险,但是需要强调的是,应用程序员必须明确地实现被加密的信令方法,这个功能才有用。
  7、额外的安全性话题
  电信网络的脚本
  通过给WebRTC提供支持,一个电信网络不应该被暴露在安全隐患中。但是,用户手中的设备和软件会不可避免的可能受到不法人员的攻击。
  因此,所有从未信任源(也就是消费者/用户)接收的数据必须要经过验证,电信网络必须认为任何发送给用户的数据都有可能被心怀恶意的人窃取。
  为了达到这两点,电信供应商必须努力尝试所有可能性,来保护消费者不会因为他们自身的错误而暴露自己的系统。
  跨站脚本(XSS)
  跨站脚本(Cross-site ing)是网页应用中一个典型的易受攻击点。它可以使攻击者侵入网页的客户端脚本。跨站脚本的弱点可能被攻击者利用,来绕开像来源规则一样的连入控制。
  跨站脚本的影响可能微不足道,也有可能造成严重的安全隐患,要看网站所处理数据的敏感度以及网站所有者是否用了任何能够抑制安全性的东西。
  因为访问WebRTC应用的主要方法是使用可运行HTML5的浏览器,所以有一些特定的安全性考虑比如;保护密钥和敏感信息免受跨站脚本或挂域名的攻击,WebSocket的使用,iframe的安全性,以及其他问题。因为客户端软件是由用户自己所控制的,绝大多数情况不由浏览器所控,所以WebRTC的用户需要尽可能的在安全受保护的环境下使用软件。如果不是的话,用户所发送的所有数据都会暴露。
  8、总结
  在现在这个智能手机和移动设备广泛使用的时代。加密技术在近些年成为了一个很大的话题,也有很多大公司被窃听以及政府大范围电信窃听的丑闻传出。这导致了用户对这些公司或组织的不信任度迅速上升,并且要求安全性方面要有很大的提高。所有终端用户都想要知道他们的个人数据是否处于可控的私密范围内。
  在安全性领域,WebRTC要远优于大多数VoIP服务。知道现在,很多服务通常都将安全性视为可有可没有的性能,意味着大多数终端用户使用VoIP的通话都没有被加密。通常大公司是这件事请的始作俑者,为了节省预算而不考虑他们所处理的用户数据的价值。但是因为WebRTC禁止未经加密的通信建立,用户可以放心他们的数据都是安全且私密的。
  最初设计WebRTC时,安全性就是设计的目标之一,所以WebRTC强迫或者鼓励在所有主要部分中使用重要的安全性理念。同样因此,与简单的内置安全性一样,WebRTC也鼓励它的开发者严肃看待他们的安全性问题。
  作为着重关注安全通信的结果,WebRTC目前被视为最安全的VoIP方案之一。默认进行加密的主要前提是通话在所有时候都是私密的。安全和加密不再被视为可选特性。并且WebRTC对于所有人来说都是免费的,给开发者提供了一个诱人的可靠的框架,用来搭建他们的下一个应用。
  在不远的将来,我们可以期待看到越来越多的通信服务都可以给他们的用户提供大程度提高的安全保证。但是现在,WebRTC是这方面的领军者。
【免责声明】本文仅代表作者本人观点,与CTI论坛无关。CTI论坛对文中陈述、观点判断保持中立,不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。请读者仅作参考,并请自行承担全部责任。

专题