Total Pageviews

Sunday 13 May 2012

理解SSL窃听

近日在网络传得比较离谱的一条消息是对TLS/SSL应用层的窃听。随着瓷翁生日的临近,长城似乎有越蹦越高的趋势,导致不少人对SSL v3的安全性也产生了怀疑,这里客栈尝试用简短的图文解释一下所谓的窃听如何完成,以及通过什么方式避免。

首先要强调的是,目前没有对SSL v3这个安全协议的可行攻击;所有窃听均需利用客户端(浏览器及用户)的弱点执行,而非对协议本身的直接攻击。
So, in before the fear spreads…
SSL会话破解有三种主要方式一是通过嵌入系统获取密匙,二是通过巧妙的方式进行Cryptanalysis(密码分析),三是设立中间人执行MITM攻击。
假如攻击者能入侵用户主机或服务器,那用户资料就直接沦为刀俎了,再绕道SSL属于白费力气。因此保持个人系统安全对防止第一类“破解”尤为重要。攻击者并不是在破解SSL协议,而是在直接想办法和你的系统挂钩,盗取加密前和解析后的信息。

本地分析加密会话很简单,类似Http Analyzer的软件支持IE,Firefox,Chrome和Safari几款浏览器的请求记录,它们是站在用户与浏览器之间的看客,而非本地与远程主机之间的黑客(对于不支持的软件,例如Opera或Putty,它是无法记录HTTPS请求的)。
第二种方式因缺乏有效的密码分析,并没有实际应用;SSL v3本身没有已知漏洞,解开会话需要利用客户端和服务器端的漏洞完成(获取密匙);等同第一类攻击了。

相比之下,最可行的SSL窃听方式是第三类:通过MITM。无需获得密匙,无需本地木马,远程窃听者通过建立两条链接:一条从窃听对象到窃听服务器,另一条从窃听服务器到目的服务器,尝试偷换身份并做到会话窃听。
之前我们也说了,协议本身并没有漏洞,因此浏览器的安全设计和用户的安全意识就成了最受考验的部分。第三类攻击要生成不合法的证书,当今的浏览器在遇到该类证书时都会提示错误,但信息的表达方式各不相同,误导用户接受非法证书也时常发生。

Chrome 3-beta的警告是最显眼的。

Firefox 3.5的警告需要阅读,也算显眼的。

Opera 10的警告包含有用信息,但未必能帮助分析。

Safari 4 on Windows的警告和普通提示没什么区别,一点就过了……

IE7的警告够简洁,但解释不足。不知道IE8如何(安装不能,无法测试)。

IE6的警告有够误导,以多数票计算,这是可以接受的对吧?
为了更好地测试各浏览器在MITM攻击下的反应,这里使用Stanford教学用的简单SSL MITM Proxy来测试。具体设置如下:
先准备好浏览器与Java。下载工具并解压压缩包后,使用命令行工具,转到该目录,并输入以下命令(Linux用户请看Readme)。
java -cp iaik_jce.jar; mitm/MITMProxyServer -localHost localhost -localPort 8001 -outputFile output.txt -keyStore FakeCAStore -keyStorePassword passphrase -v

这样就会在本地设立一个窃听用的Proxy,它会尝试修改所有加密链接发送的证书,将自己寄生在加密连接上。(注意该Proxy并不需要安装在本地,它可以安装在信息途经的任意服务器上,包括任何Tor节点。)

配置浏览器使用这个代理(localhost:8001),模拟请求通过远程的窃听服务器。和目的服务器配上之后,Proxy就会接收原证书,并制造假证书发送给浏览器,这时浏览器应该提示错误。

假如用户选择接受该证书,则余下的通信可被监听,这些通行将被记录在本地的output.txt,各位可自行瞻仰其详尽程度。

如果你看到的传输内容是一大串数字,请看Encoding是否启用了gzip,那是gzip后的网页数据;Amazon不启用gzip,直接返回HTML代码。
一个简单的SSL窃听就是这样完成的。但如何防止呢
I. 认真检查URL——这是废话,但也是最致命的用户疏忽。

II. 不要接受非法证书——当前用户关注度不足。
尤其是在存放了个人信息的网站。例子中的非法证书替换了发行者的部分(替换为locahost和stanford),是非常好辨认的错误。实际应用中,普通用户将很难分辨证书的真伪,这时选择拒绝才是上策,不管你有多信任该网站。
对于部分没有证书却强迫使用HTTPS的网站,请避免提交任何涉及个人隐私的信息,以免发生意外(接受非法证书将建立未验证的加密连接,用户和网站都没有办法判断是否有人窃听该链接)。
最后是检查CA机构,CA机构告诉浏览器是否应该相信一个网站:假如你不信任签发证书的那家CA,那它验证的网站你也不应相信(浏览器均内置了CA列表,但根据浏览器的不同,它们支持的CA数量也略有不同)。

III. 不要允许SSL v1和v2——过期的SSL版本。
SSL v1和v2都有已知漏洞,不要允许浏览器降至这两个级别。主流浏览器都有禁止老加密协议的选项。

IV. 使用现代化的浏览器——你想要安全,却继续使用IE6核心?
有些网站存在HTTPS与HTTP混用的问题,这时要小心拦截。虽然无法在远程修改被加密的对象,但未加密对象是可以修改的;若有攻击者插入隐藏表 格或JS代码,数据可能被提交至第三方服务器,而用户不会察觉曾被窃听。IE7+会提醒用户有关“安全与不安全内容同时存在”的问题。
(我发现Opera 10和Safari 4都比较沉默,不会提示“存在未加密对象”,是我没设置对还是它们不受影响就不清楚了。)
实际应用中,由于SSL窃听十分耗费资源,是无法大规模长时间实施的;若你在浏览时经常碰到证书错误的情况,请尝试换用浏览器以排除软件上的错误。若情况继续,祝君好运……话说回来,收买CA机构也许比购买窃听服务器便宜得多;所幸咱们这边没什么大型的CA机构,否则……
大体的解释就这么多了,欢迎留言指教。
完。
2009-09-28 更新添加了备注,欢迎指教。
来源http://bitinn.net/5087/
==========
《理解SSL窃听》一文的备注
以下内容在写原文的时候觉得和SSL窃听关系不大,就没加入,这里补充给有兴趣的读者。

关于认真检查URL——请不要只依赖浏览器的“正面反馈”(Positive Feedback)和“负面反馈”(Negative Feedback)进行判断。BlackHat会议几年间公开过的SSL“漏洞攻击”,均是配合浏览器的存在弱点,回避负面反馈,制造虚假的正面反馈来迷惑用户。手段包括替换favicon,通过IDN仿造URL和利用CA认证漏洞等等。有些网站在HTTP登录表格旁附上锁头图片,本身也是一种误导。
关于Cryptanalysis(密码分析)——虽然SSL本身的匙交换没有漏洞,但证书的验证一直是研究人员攻击的对象。2008年末有一队研究人员成功构建了MD5的碰撞哈希(使用200多台PS3和几十张合法证书),证明用MD5算法构造的证书均可以被伪造。不过该证书早已过期,而大部分CA(包括Verisign和Comodo)都已转用SHA-1作为加密算法;用户只要保证系统时间的正确,足以防止攻击者利用现有伪造证书。
关于信任CA——我在文中已提及了少数CA认证流程上的不谨慎,而他们又是除OCSP外的主要验证关卡,因此对CA的检查是首要的(你可以删除不信任的内置root CA,在浏览器选项里)。如今严峻的工作是促进CA扫荡曾经签发的不安全证书,民间亦有偏方,包括SSL Blacklist插件。
注意:root CA使用什么算法并不重要,重要的是中间层使用的算法。浏览器本身信任root CA,因此不会验证他们的证书解释1解释2。)
简单点说,有足够CS知识的攻击者会尽量伪装自己(某些工具能混合多种攻击),但他无法破解SSL:一个警觉的用户也有办法及时察觉异样。
推荐阅读:Decrypting A Wireshark Capture With Ssl Traffic
image via flickr
PS:由于有很多·Linux·users喜欢看到自己的OS,客栈更新了UA检测。这里重申,那东西只是看着好玩,用什么OS是你自己的事。
来源http://bitinn.net/5122/

相关帖子: http://briteming.blogspot.co.uk/2011/11/few-ideas-for-your-proxy-20.html
--------------------------------------------------------------------------------------------

GFW发飙,SSL窃听?


GFW发飙,SSL窃听?

Published on Fri 25 Sep 2009 12:09 ( 1 year, 2 months ago)
据说GFW发飙了,大部分翻墙措施,包括Tor都被攻陷了。via @iGFW
# GFW今天发飙了,各路翻墙楼梯将被锯掉,#GFW 
# PUFF 倒下 #GFW 
# UltraVPN、AlwaysVPN、AlonwebVPN、YourFreedom倒下 #GFW 
# Hotspot、Itshidden、CybeyghostVPN倒下 #GFW 
# 大量PHproxy、GlypeProxy、Appspot.com上的Proxy、Psiphon倒下 
# Freedur、Skydur倒下 
# Gladder、Phzilla倒下 
# Skydur倒下 #gfw 
# Tor、JAP正慢慢倒下 
# Phproxy类Web代理被群奸,建议嵌套一次用。用一个Web代理套另一Web代理再操 #GFW 
# JAP也就是现在的Jondo,和Tor是共用节点和桥的 
# glype已经和phproxy一起废了 
# 用Mirrorrr在GAE上搭建的众多Proxy倒得差不多了 
# Tor已完全倒下,套都破了 
# Tor死的很惨,目录服务器、桥服务、国外第一条节点等均被破解,就算将Tor套上代理成功启动(洋葱变绿)都是徒劳。 
# Puff 惨遭 #gfw 追杀,最新0.03b2版本倒下
无独有偶,看到一个前Netscreen出来的创业公司的产品的介绍,其中谈到它能够截获SSL通讯并进行“审计”,相当恐怖:
对外发信息进行审计,防止机密外泄及不必要的法律纠纷,是UTM Plus中上网行为管理模块的另一大作用。该模块对HTTP、FTP、SMTP和主流即时通信类应用提供了由信令到内容层面的审计能力,莫说论坛发帖,就连163、Hotmail、Gmail、QQ邮箱等国内应用比较广泛的Webmail发信都被囊括在内。妄想使用Gmail等采用HTTPS登录的Webmail逃避检查也是徒劳的,UTM  Plus内置的SSL代理可以截断所有单向验证的SSL请求,对解密后的内容进行控制、审计。也就是说,利用这个代理,一切基于SSL隧道的应用协议都被纳入控管范围,不会再有漏网之鱼。不过,我们也注意到内容审计功能开启时,客户端并不会得到任何提示,山石网科称会在产品正式发布时以告警提示和法律免责申明的方式加以完善。
不知道其技术实现具体细节如何,貌似是通过一个“SSL代理”来做到的,但是这个代理是对用户透明的吗? 如果是代理如何欺骗用户端的证书认证的呢? 
如果这个技术是真实有效而且透明的,一旦被GFW利用后果不堪设想啊.