如何做到窃听SSL的内容的？

[wanghx]

From: maverick
Date: 2009/9/25
Subject: 如何做到窃听SSL的内容的？

看到一篇文章（http://www.tektalk.cn/2009/09/25/%e8%bf%9b%e5%8c%96%e7%9a
%84%e8%89%ba%e6%9c%af%e2%80%94%e2%80%94hillstone%e5%b1%b1%e7%9f
%b3%e7%bd%91%e7%a7%91sg-6000-g5150%e4%ba%a7%e5%93%81%e8%af
%84%e6%b5%8b/ ）介绍一个国内的安全厂商方案，其中提到：

对外发信息进行审计，防止机密外泄及不必要的法律纠纷，是UTM Plus中上网行为管理模块的另一大作用。该模块对HTTP、FTP、SMTP和主
流即时通信类应用提供了由信令到内容层面的审计能力，莫说论坛发帖，就连163、Hotmail、Gmail、QQ邮箱等国内应用比较广泛的
Webmail发信都被囊括在内。妄想使用Gmail等采用HTTPS登录的Webmail逃避检查也是徒劳的，UTM  Plus内置的SSL代理可
以截断所有单向验证的SSL请求，对解密后的内容进行控制、审计。也就是说，利用这个代理，一切基于SSL隧道的应用协议都被纳入控管范围，不会再有漏
网之鱼。不过，我们也注意到内容审计功能开启时，客户端并不会得到任何提示，山石网科称会在产品正式发布时以告警提示和法律免责申明的方式加以完善。
－－－

讨论下这时如何做到的？

如果这种技术的确存在并成熟被GFW获得将是灾难。

[mon...@gmail.com]

wanghx 写道:

完成破解SSL的唯一可行方案是（当然，前提是加密算法是安全的，这一前提普遍
适用）：
A与B通信，中间经过代理P
不涉及具体加密算法和密钥协商协议的细节，从概念上讲是这样的：
A和B协商密钥，正常情况下，A和B说：我们一起用K作为密钥（具体情况下不会把K
写在明文里，而是采用比如PKI等体系，利用非对称密钥加密算法来传递密钥K），
然后B对A说：好的，我们用K做密钥。之后，A和B的通信就都采用了密钥K
假设此时P在中间收到了这个消息，截获了它，然后修改这条消息，冒充A，对B
说：我们一起用L作为密钥。然后B传递消息给A，说：好的，我们用L做密钥。但是
这消息在传递过程中，P截获，修改后冒充B，传递给A说：好的，我们用K做密钥。
此时，通信的结果就是：A和P使用K加密传输，P和B使用L加密传输。P在中间就可
以获得A与B通信的全部内容。

这种中间人攻击是一个非常大的问题。对于GFW来说，它实现这种攻击的条件——控
制了全部的中间节点。但是对它来说也同样存在困难：以现在的效率，处理如此大
流量的数据已然有些吃力了，如果继续加入这种中间人攻击的功能，可能带来两个
结果——1. GFW全面扩大，很多计算节点加入，增加GFW能力。显然，这一点一直都
在进行。2. 相对于需求来说，GFW的能力总是不够的，或者说在有限的时间内，也
许GFW的能力很难满足要求。但为了满足监控的目标，我们可能迎来有史以来最低
速的宽带网络。这一点也同样可怕。因为这样的话很多多媒体应用讲不复存在。

现在说说解决中间人攻击的办法吧。Tor采用的洋葱加密算法就可以解决这种问
题。这就是为什么说Tor是一个匿名访问系统（anomalous system），而一般的代
理并非是匿名访问系统。简单说来，tor的算法出于一个很简单的想法：层层加
密。就好像洋葱一样一层一层的。具体内容可以参考 tor的论文或者演讲视频。在
官方网站上有。理论上讲，在这种网络内部（tor网络内部）传输消息是安全的。
但是在网络出口处（比如tor网络和web网络的边界节点）的信息则是不安全的。然
而，我们用tor的话很少有人只是用它在tor网络内部传递消息。大多数人（我想应
该是全部人）都tor网络作为代理访问web网络。所以如果我是GFW的管理者，我就
会在国内设立几个tor节点，在出口节点处完成中间人攻击。这样收集到的信息肯
定都是非常有用的—— 对GFW及其所属的整个国家机器而言。

同时，tor网络本身也存在问题：tor不是一个p2p网络（这一点在tor论文和演讲中
已经明确说明了，可是还有很多人搞错……）。虽然tor是分布式的，但由于它的节
点无法动态地加入和退出，所以不能说它是p2p网络。tor的节点都是志愿者贡献
的。这样就导致了有固定的目标，让GFW可以封（据说最近这阵子tor也不好用了，
我这几天不在墙内，所以没能证实这事）。

tor的论文中提到了几个p2p的匿名访问系统，还有一些匿名访问系统的文章在这里
可以看到： http://freehaven.net/anonbib/topic.html#Anonymous_20communication

考虑到这里可能有些人没有技术背景，我尽量把问题描述得口语化。这样难免会有
失严谨，还望见谅。我最近也在考虑设计一种更好的翻墙方法，目前正在实现中，
不过由于手头的事情比较多，所以进展缓慢。代码也在调试。有兴趣的朋友欢迎来
一起讨论。

--
Regards

Monnand
Email: mon...@gmail.com
GTalk: mon...@gmail.com

[wanghx]

现在讨论的这个安全漏洞，和加密强度毫无关系。换 256 位加密也没用。

对 SSL/SSH 的中间人攻击方法[11]，早些年就有讨论[3][4][7]-[10][12]-[21]。今年又提出来[23]，是因为中共国有网络监控产品声称可以 截取并监控 HTTPS 通信内容[22]。今年国际上有一些论文讨论了浏 览器 SSL 网页访问在实 现上的设计漏洞，可能误导用户信任不可信的网页内容[2][5][6]。须注意，一个加密体系虽然理论上非常完善，但是在应用实现中的种种复杂问题可能导 致实际 上的大量漏洞。针对这些漏洞的攻击，远比针对加密和安全验证算法强度本身的攻击多样化且实际上可行度大得多。事实上大部分用户是被木马病毒，虚假网页所欺 诈而泄密，而不是直接暴力解密而泄密。

注意“单向验证”这一点。估计就是针对非双向验证身份的 SSL 进行中间人攻击。

http://www.google.com/search?hl=en&q=ssl+man+middle+attack&aq=f&oq=&aqi=

这个漏洞的核心问题在于，现有的所有提供 HTTPS 链接的网站，比如 gmail，都在网页上混有不加密的部分内容，这造成用户的麻痹大意，无法区分其浏览的页面是否真正被加密，或者是否真正都是和可信的服务器通信。

比如，如果 gmail 页面上一部分内容来自 mail.google.com，另一部分内容来自 doubleclick.com，如果 mail.google.com 的链接使用强认证的扩展认证(EV) SSL 证书[1]加密，而 doubleclick.com 不加密，或者只采用认证域名的证书(Domain Verified Certificate)，那么，浏览器依然会显示说这个网站是加密链接，而且证书的数字签名验证正确，尽管网页上只有部分内容是来源于可信网站。

利用浏览器安全设计上的这一点漏洞，可以截取网络通信内容，替换部分网页内容。这些来自虚假服务器的内容，也是经过虚假服务器的证书签名和加密的。这样， 从大部分不 细心的用户看来，他们是在通过加密的连接通信，而忽略了网页上部分内容来自真实的服务器，部分内容来自虚假的欺诈服务器。提出这类中间人攻击方法的论文作 者们提 供的解决方案是：

1. 仔细检查 root certificate 不要混入虚假的证书。
2. 网站设计者应该注意，凡是安全加密的网页，所有内容都应该加密。
3. 用户应该注意，设置浏览器，拒绝加密网站上的任何非加密或者非强认证(EV)证书的链接。
4. 浏览器应该改进设计，把网页上所有服务器的证书以清晰明确的 方式告知用户。

结论：

目前针对 SSL 的中间人攻击手段，是一种欺诈术，而不是破解了 SSL 加密体系。尽管如此，这些攻击方法是高度有效的。因为目前主流浏览器处理 HTTPS 网站的通常方式，以及提供加密链接的网页上通常混合有复杂的来自不同服务器的聚合内容（比如广告），造成对数字证书是否真实有效的判断非常麻烦，而用 户缺乏安全常识或者警惕性不高的情况下，非常容易上当。

参考：

[1] http://en.wikipedia.org/wiki/Extended_Validation_Certificate

[2] Tim Callan's SSL Blog - Online Security: EV SSL and iFrame attacks https://blogs.verisign.com/ssl-blog/2009/07/ev_ssl_and_iframe_attacks.php

[3] sshmitm and webmitm implement active monkey-in-the-middle attacks against redirected SSH and HTTPS sessions by exploiting weak bindings in ad-hoc PKI; December 2000; http://www.monkey.org/~dugsong/dsniff/

[4] michael: Attacks Against SSH 1 And SSL; Mon Dec 18, 2000 07:09 AM; http://slashdot.org/it/00/12/18/0759236.shtml
[5] Man in the middle attack against Extended Validation protected Web sites; http://aaa-sec.com/web/blog_files/51eed15e5c72e76a760b5bf146d68834-25.html
[6] Hacker pokes new hole in secure sockets layer; http://www.theregister.co.uk/2009/02/19/ssl_busting_demo/
[7] Ted Shorter: A Real Life Man-in-the-Middle Attack on SSL; RSA Conference 2005; February 15, 2005; http://www.docstoc.com/docs/11837353/A-Real-Life-Man-in-the-Middle-Attack-on-SSL
[8] ITP: sslsniff -- SSL/TLS man-in-the-middle attack tool - Debian Bug report logs; http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542472
[9] Peter Burkholder: SSL Man-in-the-Middle Attacks; February 1, 2002; http://www.sans.org/reading_room/whitepapers/threats/ssl_maninthemiddle_attacks_480?show=480.php&cat=threats
[10] Man-in-the-middle attack sidesteps SSL; http://www.securityfocus.com/brief/910
[11] Man-in-the-middle attack - Wikipedia, the free encyclopedia; http://en.wikipedia.org/wiki/Man-in-the-middle_attack
[12] "Passwords Found on a Wireless Network", D. Song, USENIX Technical Conference WIP, June 2000; http://www.monkey.org/~dugsong/talks/usenix00.ps
[13] "Network Monitoring with Dsniff, LinuxSecurity.com, May 2001; http://www.linuxsecurity.com/feature_stories/feature_story-89.html
[14] "On the lookout for dsniff, part 2, IBM DeveloperWorks, February 2001; http://www-106.ibm.com/developerworks/security/library/s-sniff2.html?dwzone=security
[15] " On the lookout for dsniff", IBM DeveloperWorks, January 2001; http://www-106.ibm.com/developerworks/library/s-sniff.html
[16] "dsniff and SSH", O'Reilly Sysadmin News, December 2000; http://sysadmin.oreilly.com/news/silverman_1200.html
[17] "The End of SSL and SSH?", SecurityPortal, December 2000; http://securityportal.com/cover/coverstory20001218.html
[18] "Catch Hackers in the Act", CNET Web Builder, December 2000; http://www.cnet.com/webbuilding/0-7532-8-4011019-4.html
[19] "Why Your Switched Network Isn't Secure", SANS Institute, September 2000; http://www.sans.org/newlook/resources/IDFAQ/switched_network.htm
[20] "Switched networks lose their security advantage due to packet-capturing tool", InfoWorld magazine, May 2000; http://www.infoworld.com/articles/op/xml/00/05/29/000529opswatch.xml
[21] "Think you're safe from sniffing?", Windows 2000 magazine, June 2000; http://www.ntsecurity.net/Articles/Index.cfm?ArticleID=8878
[22] 一切基于SSL隧道的应用协议都被纳入控管范围 https://groups.google.com/group/lihlii/browse_frm/thread/b0e5a18ac57a008f
[23] 如何做到窃听SSL的内容的？ https://groups.google.com/group/lihlii/browse_frm/thread/a8307a015a32c73f

AndyR writes:

"SecurityPortal has a very interesting article by Kurt Seifried in which he writes "dsniff 2.3 allows you to exploit several fundamental flaws in two extremely popular encryption protocols, SSL and SSH." He makes many very strong arguments about key validity and the problem with not having a trusted third party signing keys."

2009/9/25 佐拉

我 在别人的提醒下，给firefox加了一个插件，访问gmail会启用256位加密，而不是Google的https默认的128位 RC4加密,据说可被破解。
安全第一，常改密码是好策略。

在 2009-09-25，GFW WTF 写道：

> MITM。Blackhat 09今年有paper。工具是SSLStrip。

from    TanCee
date    Fri, Sep 25, 2009 at 6:11 PM
subject    Re: 如何做到窃听SSL的内容的？

http://google.org.cn/posts/check-your-google-account.html#comment-4305
事实上，由于key scheduling算法的缺陷，AES-256的安全性不如AES-128，而目前最安全的是AES-192(不过很多地方都没有使用)。我的博客上记 录了最近的几个攻击。

我是不明真相的群众，来个高人指点下~

--
请不要轻信没有正确 OpenPGP(GPG) 数字签名的来自本人 email 地址的任何邮件中的链接和附件，以防假冒。 我的公钥: http://j.mp/pubkey

[wanghx]

gtalk 只用 ssl 连接 gtalk 的服务器，不存在目前讨论的 HTTPS 网站可能因为
浏览器设计上的缺陷而有安全漏洞的问题。SSL 没有破解。>@tianchaoren 传闻
ssl加密的gtalk也能被实时监控，说是gfw那些人已经能实时破解ssl。
http://twitter.com/lihlii/status/4374203363

[wanghx]

Q: 这也就是说如果我所有的行为都使用 MyEnTunnel 的ssl进行就不可能被监控，对吧？

A: 并非使用某个软件就一定能防范中间人(man-in-the-middle, monkey-in-the-middle)攻击。对这种攻击的防范高度依赖用户的行为习惯，软件界面的设计是否对异常有充分的警告，而不是加密体制问 题。当你看到 host key 改变的时候，如果没有你能确信的充分的理由（比如你自己重新安装对方远程的机器改变了 pubkey 或者证书），你得拒绝这种连接。否则，你依然会中计。

现在的网站内容聚合来源非常复杂，因此使得安全网页的判断成为一个难题。这一点提示安全网站设计者，在需要 HTTPS 加密连接保障信息安全的网页中，应该尽量减少页面内容来源，以防止用户习惯了接受许多不熟悉的网站的证书，而被麻痹。

Q: 能监控中文版的GTalk吧？囧。况且GTalk不是SSL加密的，是TLS。

A: 中文版和英国英语等最新的版本是 1.0.0.105，都是不加密链接。只有美国英语版停留在 1.0.0.104，是加密链接。
   这里[2]有一个中文化界面的 1.0.0.104 版本，是中共国人汉化的。我测试过了，是加密链接。

   TLS 和 SSL 的原理是相同的，只是协议标准的小差异。面临的中间人攻击问题也是共同的。

   用中文或者其他语言的 1.0.0.105 版 gtalk，或者 msn/windows live messenger, yahoo messenger, AIM，Jabber/XMPP/Pidgin/Psi 的用户，可以用 simplite 来提供端到端的加密。使用还是蛮方便的。 Pidgin 本身也可以安装插件支持两种端到端的加密，其中一种是 OTR (Off The Record)插件。

参考：

1. 中文版Google Talk是未加密明文传输聊天内容 https://groups.google.com/group/lihlii/browse_frm/thread/a4264b1a4ac78c01
2. gtalk 中文版传文件问题 https://groups.google.com/group/lihlii/browse_frm/thread/4817e1da86d45271
3. http://en.wikipedia.org/wiki/Transport_Layer_Security

--

[wanghx]

修 正，具体要看 gtalk 软件是如何处理当服务器证书被篡改，数字签名不能通过的情形的，是否对数字证书进行校验。

这一点要通过试验才能确知。如果 gtalk 没有对 gtalk 服务器的证书进行强校验，那么是很大的设计漏洞，违背了 TLS 通信协议的最基本的要求。虽然基础的 TLS 通信协议库漏洞较少，但是调用这些标准库的上层应用软件的设计可能会有很大漏洞，因为往往不是安全专家设计的。

比如，当下层 TLS 通信连接建立的握手过程发现证书不匹配，函数调用返回错误信息的时候，上层软件的调用函数可能并不检查这一错误状态标志，或者忽略之。这就造成大漏洞。

gmail chat 网页对话，因为通过浏览器已有的网络连接，所以如果 gmail 中设置了总是用 https 加密访问，且注意检查 google.com 的证书和签署者证书是正确的，则可以防范中间人监听。但是对话内容在 google 的服务器上是不加密的。如果 google 公司有内鬼，依然可能被监视。

老版本的 Google Chrome 默认设置是允许混合非加密和加密网页内容，要专门设置拒绝加密网页上的非加密内容。新的 3.0 版本看起来没法设置拒绝加密网页上的非加密内容了[1]-[7]。这是安全隐患。
而 MSIE 和 Firefox 都会提醒这种情况。

对于服务器证书未通过强认证的情况，MS IE 默认会提醒要求确认。Firefox 默认提醒一次，可以选择以后都忽略，这虽然方便，但是也埋下安全隐患。建议 Firefox 用户检查一下安全设置：Tools / Options / Security / Warning Messages / Settings，选中所有的安全警告选项。

但是对于最近一些论文提到的中间人攻击方法，这些浏览器都很难使用户发现，看似加密的页面上其实有些加密内容是来自虚假的服务器。也就是说，尽 管你看到浏览器显示加密链接状态的小锁，但依然可能你在和虚假的中间人服务器通信，而不是直接和真实的服务器通信。虽然 SSL 协议本身包括对这种欺诈的防范措施，但现有的浏览器的设计并没有充分考虑这种欺诈隐患。

另一个重要的安全隐患，是不可信的根证书和证书颁发机构。这样可以通过安装虚假的根证书，来欺骗用户认为是和真实的服务器通信，而注意不到中间 人截取信息的事实。

有些软件的安装，会加入自己的根证书(root certificate)，比如中共国内一些网上业务软件，淘宝(alipay, alibaba), iTruschina 等等。这些根证书服务商，完全可能和黑帮合作，为间谍软件签署虚假证书。所以要检查系统中的证书，将所有中共国以及不可信的证书从根证书，信任证书颁发机 构中删除，并要经常检查这些证书列表。需要公布一份可信的，和不可靠的根证书颁发机构的证书列表。

参考：

1. Chrome 3.0.193.2 -- where is the option to not load insecure page elements? http://www.google.com/support/forum/p/Chrome/thread?tid=78f71260f949a25d&hl=en
2. Why do I get "this page contains some insecure elements" for https:// page http://www.google.com/support/forum/p/Chrome/thread?tid=3a81f282a695c5a3&hl=en
3. "... page includes resources which are not secure" crap with Gmail http://www.google.com/support/forum/p/Chrome/thread?tid=78242d49c14fceb8&hl=en
4. "Your connection to XXX is not encrypted" (3.0.193.2) http://www.google.com/support/forum/p/Chrome/thread?tid=24d336876a1b2118&hl=en
5. http://www.google.com/support/forum/p/Chrome/thread?tid=4b3b96ce7048a28e&hl=en http://www.google.com/support/forum/p/Chrome/thread?tid=4b3b96ce7048a28e&hl=en
6. Google Chrome: Insecure Content ('mixed content') http://grok.lsu.edu/mobile/Article.aspx?articleId=9392
7. Customizing Google Chrome Settings http://www.downloadgooglechrome.co.uk/customizing-google-chrome-settings/
   List of default settings
   Security and privacy:
   All types of mixed content are displayed.
   
   Warning signs The following signs warn you of possible web dangers:
   If mixed content is detected on a secure webpage, an alert icon appears at the end of the address bar. You can click the icon to open the ‘Security information’ dialog box and see more information. To obtain details about the certificate presented by the website, click the Certificate information button. Learn more about controlling the display of mixed content.
   
   

   Mixed content or insecure content

   Sometimes, an SSL-secured website (denoted by ‘https’ in its web address) loads parts of its content from insecure resources. Content from insecure sources can be viewed by others as a webpage is loading and information is transmitting. Malicious parties could potentially modify these insecure resources and change the look and behavior of the webpage without your knowledge or consent. By default, all content is displayed, but an alert icon appears at the end of the address bar when you encounter a webpage with mixed content. Set preferences for displaying mixed content

   1. Click the Tools menu.
   2. Select Options.
   3. Click the Under the Hood tab.
   4. In the ‘Security’ section, select your preferred display level in the drop-down menu labeled ‘When there is mixed content on secure (SSL) pages.’
      • ‘Block all insecure content’: With this option, broken image icons appear in the place of insecure images. Frames and iframes are replaced by a red box. You can override this setting for a particular webpage during your current browsing session by clicking on the Show all content link on the message that appears at the top of the page.
      • ‘Allow insecure images’: Insecure images load, but are marked so that you can identify them.
      • ‘Allow all content to load’: All web elements load regardless of their security state.
   5. Click the Close button.

   Insecure content alert If you’ve selected the option to block insecure content, Google Chrome displays a message at the top of the page if you visit an SSL-secured webpage with insecure content detected. Click the Show all content link to let Google Chrome load all web elements only if you accept the possibility that your connection might be intercepted, or click the x icon to dismiss the bar. Clicking the link overrides the preference level you’ve set for the current webpage during your current browsing session.
   

2009/9/25

gtalk 只用 ssl 连接 gtalk 的服务器，不存在目前讨论的 HTTPS 网站可能因为
浏览器设计上的缺陷而有安全漏洞的问题。SSL 没有破解。>@tianchaoren 传闻
ssl加密的gtalk也能被实时监控，说是gfw那些人已经能实时破解ssl。
http://twitter.com/lihlii/status/4374203363

[wanghx]

2009/9/27 86
不知道我这样理解有没有错

使用浏览器通过MyEnTunnel的socks本地代理连接到境外主机，不论访问内容是否为https，都应该是加密的，但MyEnTunnel 的证书验证机制可能导致中间人攻击的发生，而所访问https网站的加密等方面的漏洞不会直接导致内容被截获。

Users and other "soft" factors (economy, psychology, sociology) are the reasons why security often fails; not errors in logic or in the application of mathematics.

- Adam Shostack and Andrew Stewart, "The New School of Information Security", Pearson USA 2008. [24]

精确地说，不一定是 MyEnTunnel 的证书验证机制有问题，而可能是你看到了证书验证提示异常信息而没有加以重视。MyEnTunnel 是控制 plink (putty) 建立 SSH 通道的。其中任何一个环节的忽略，都可能导致问题。plink 是会提醒证书修改的异常，但 MyEnTunnel 是否让这种异常也以清晰方式显示出来，则需要测试。

另一方面，应用层，表示层以上的安全机制缺陷(比如网站页面内容，人机交互界面，客户端脚本，不安全的证书提示信息)，一样会使得会话，传输层以下的安全 机制（TLS/SSL 是传输层安全机制）失效。因为你要加密的目的最终是保护应用层信息。比如，如果你通过加密通道，结果访问了一个欺诈钓鱼网站，一样会泄露身份信息，丢失密 码。这种欺诈是直接攻击到你脑子里的经验和理性，攻击你的真实社会关系，而不仅仅是计算机软件的层次。:) 一个缺乏安全防范，不谨慎的用户，是无法用软件来防止他出错上当的。

使用 SSH/SSL Tunnel (plink, MyEnTunnel, stunnel)时，为了防止中间人攻击，最好的方式是在本机 生成远程机器的证书，传递到远程计算机，然后在建立连接时，确认一下对方的证书指纹和本地保存的原始证书的指纹一致，没有被中间人篡改。同时，最好双方都 采用证书验证，而不是单向验证身份。

大多数情况下，为了客户端访问的便利，我们都不采用客户端证书进行身份验证。但当你同时拥有一个加密通道两边主机的控制权的时候，最好应该采用 双向身份认证，以提高对抗攻击欺诈的能力。

SSL v2 有一些漏洞[23]，目前的 v3 修补了这些漏洞。协议的实现，比如 OpenSSL, OpenSSH 都难免有安全漏洞。但从我对看到相关文献的理解，目前讨论的这些攻击手法，不是针对 SSL/SSH 协议本身的漏洞，而是采用这些协议上层应用软件处理不当，缺乏足够安全常识的用户对于证书改变无法获知，或者很容易忽略而导致。

所以，再怎么强调都不为过，真正的安全加密体制的困难，是如何设计软件使得用户能遵循安全的使用习惯，而不是加密体制和加密算法强度够大就万事 大吉了。当安全加密软件普及到非专业人群的社会大众的时候，安全的瓶颈根本就不在加密算法或者加密体制本身，而在于用户的缺乏常识的难题了。要培训用户是 一件非常难以确保的事情。

以后的安全软件设计努力，应该在如何从用户交互界面上，防范不安全的使用习惯（这可能带来一些麻烦），以及安全软件的开发团队中，安全加密专家 和非安全软件专家之间的沟通配合问题。

引起警惕的文献[22]中提到可以监控一切 SSL 通信，我根据所看到的相关研究报告推测，可能是通过截取 SSL 建立请求，以中间人身份去和真实加密服务器联系，而中间人和客户端之间不加密，或者用虚假的证书进行加密通信。一个真正对安全敏感的用户，采用界面设计合 理的软件，应该是很容易发现这一被监控的事实，虽然他如果不采用特殊的加密通道，就无法回避这种监控措施。SSL 协议本身是很容易被掌握路由器的攻击者截断和禁止的，就是让你用不成加密。这种监控措施的更阴险的危险之处在于，它不是禁止 SSL 协议，而是用欺诈的方式让用户误以为在加密通信中，而事实上并没有和真实服务器建立直接的加密通道。这样因为对 SSL 通信中证书的验证不仔细，误认为处于安全通信状态，而带来比没有加密 更大的危险。

所以说，错误的软件界面设计和使用习惯会使得采用安全加密软件比没有安全加密软件更危险。这是一个普及安全软件应用技术的大难题。比如，明明瑞星，上网助 手，360安全卫士这类软件是流氓公司出品的软件，但是大多数用户依然信任并采用这类信用奇差的流氓软件来反流氓，保护他们的计算机的通信安全。这是引狼 入室。计算机信息安全研究中有句名言，安全软件的定义是，那些能威胁你的安全的软件。那些用于安全防范的软件，恰恰是你最信任和依赖的软件，一旦出现漏洞 和被入侵，对你的安全损害也最严重。

参考：

[22] 一切基于SSL隧道的应用协议都被纳入控管范围 https://groups.google.com/group/lihlii/browse_frm/thread/b0e5a18ac57a008f
[23] http://en.wikipedia.org/wiki/Transport_Layer_Security
[24] Secure List Server: Mailman, PGP and S/MIME  http://non-gnu.uvt.nl/mailman-ssls/pgp-smime/talk/mailman-pgp-smime-talk-ulm-2009-01-12.pdf

2009/9/26 w

Q: 这也就是说如果我所有的行为都使用 MyEnTunnel 的ssl进行就不可能被监控，对吧？

A: 并非使用某个软件就一定能防范中间人(man-in-the-middle, monkey-in-the-middle)攻击。对 这种攻击的防范高度依赖用户的行为习惯，软件界面的设计是否对异常有充分的警告，而不是加密体制问 题。当你看到 host key 改变的时候，如果没有你能确信的充分的理由（比如你自己重新安装对方远程的机器改变了 pubkey 或者证书），你得拒绝这种连接。否则，你依然会中计。

现在的网站内容聚合来源非常复杂，因此使得安全网页的判断成为一个难题。这一点提示安全网站设计者，在需要 HTTPS 加密连接保障信息安全的网页中，应该尽量减少页面内容来源，以防止用户习惯了接受许多不熟悉的网站的证书，而被麻痹。

from    佐拉
date    Sun, Sep 27, 2009 at 6:47 AM

两个链接
CipherFOx能改128位加密的SSL为256位的 : https://addons.mozilla.org/zh-CN/firefox/addon/8919

OTR加密你的pidgin对话 http://www.cypherpunks.ca/otr/
pidgin http://pidgin.im

[wanghx]

http://wuhongsheng.com/it/2009/09/ssl-hijack/
29sep2009 Filed under: ITAuthor: 吴洪声

OK，我恶毒的心灵又开始蠢蠢欲动了。今天带给大家的是SSL窃听攻击从理论到实际操作的成功例子
SSL窃听最主要的是你要有一张合法的SSL证书，并且证书名称必须和被攻击的网站域名一致。目前各大CA都有很低廉价格的SSL证书申请，最低的价格只 需要10美元不到，甚至还有一些域名注册商大批量采购这些证书，并且在你注册域名的时候免费送你一张。
对于低廉价格的域名SSL证书，CA签发的前提只有一个：只要你有申请的域名某几个特定的邮箱，并且在CA给这个邮箱发送一封确认邮件的时候 approve就可以了。
所以，问题的关键是如何截获到这封确认邮件。但我相信某些机构是有办法能做到这一点的。
当然，还有更加简单的办法：国内不少软件在安装的时候，都会偷偷摸摸的把自己的root CA装到用户电脑里面去。Windows的安全机制让这个导入root CA的操作根本没有任何的确认信息和提示。甚至微软还提供了一个专用的小程序用于导入证书。只要你找到这些软件厂商，就可以任意生成证书，并且这些证书都 是有效的，不会出现警告。
废话不多说了，开始干活。这里sohu的vip邮箱为例（他们能在整个使用过程中支持ssl），先生成一张vip.sohu.com的key和csr

Sam@Bra:~$ mkdir ssltest
Sam@Bra:~$ cd ssltest
Sam@Bra:~/ssltest$ openssl genrsa -out vip.sohu.com.key 1024
Generating RSA private key, 1024 bit long modulus
............++++++
.....................++++++
e is 65537 (0x10001)
Sam@Bra:~/ssltest$ openssl req -new -key vip.sohu.com.key -out
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CN
State or Province Name (full name) [Some-State]:BeiJing
Locality Name (eg, city) []:BeiJing
Organization Name (eg, company) [Internet Widgits Pty Ltd]:fake sohu
Organizational Unit Name (eg, section) []:fake
Common Name (eg, YOUR name) []:vip.sohu.com
Email Address []:ssla...@vip.sohu.com
 
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []: vip.sohu.com.csr

well，这样我们就有了一个用于vip.sohu.com的申请了，接着我们去签发这个申请

然后系统会给你一大堆管理员相关的邮箱等你去选

选上一个后，ca就会给你所选的邮箱发送一封确认邮件，邮件中带有一个连接，打开连接后会让你确认，确认后。。。嘿嘿，证书就到手了






把申请下来的证书保存一下，然后修改下nginx的配置文件，把证书加上，并且设置一个反向代理到vip.sohu.com，大概的样子如下

# HTTPS server
#
server {
listen 443;
server_name vip.sohu.com;
 
ssl on;
ssl_certificate sslkeys/vip.sohu.com.crt;
ssl_certificate_key sslkeys/vip.sohu.com.key;
 
ssl_session_timeout 5m;
 
ssl_protocols SSLv2 SSLv3 TLSv1;
ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
ssl_prefer_server_ciphers on;
 
location / {
proxy_pass https://vip.sohu.com;
}
}

搞定，保存，重启nginx。修改本机的hosts文件，把vip.sohu.com这个域名指向 nginx所在的服务器

127.0.0.1 vip.sohu.com

打开浏览器，输入https://vip.sohu.com，你会发现。。。。根本没任何报错或者警告信 息！也就是说，ssl证书被成功替换，再就是说，你的所有传输都被劫持了。
经过测试，IE、firefox、safari等浏览器同仁纷纷表示对替换证书的行为毫不知情并对被替换后的证书予以大力支持，大肆宣扬被劫持的网站是高 可信度的网站。
回头再简单阐述这个过程：用户访问一个网站，但中间已经被插了一层proxy。proxy使用了一个真实的并且高度可信的证书与用户交换数据。用户和 proxy之间使用ssl加密通道交换数据。数据到了proxy后，会被解密并监听分析。之后proxy再模仿成一个client向网站的服务器发送数 据，同样传输也是ssl加密的。网站的服务器对此毫不知情，只能获取到是proxy发出的请求，但其实proxy并不是最终用户，数据其实早已被监听并分 析。
最后，还是应了那句话：不要迷恋ssl，ssl只是个传说
备注：
1.转载请注明出处：http://wuhongsheng.com/it/2009/09/ssl-hijack/
2.sohu的哥们不要来找我麻烦或者跨省追捕，选上你们是因为你们太安全了，支持ssl访问邮箱
3.有时间大家还是多点关注我的DNSPod，最近DNSPod正在招人，人不好找啊。。。请大家帮忙宣传下，介绍一些人才过来 https://www.dnspod.com/About/Jobs
前面一张图是sohu自己原始的证书，第二张开始就是被替换后的证书

Tags: hijack, proxy, security, sohu, ssl
You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
4 Responses to “SSL窃听攻击实操”
unixhater
September 29th, 2009 at 2:47 pm

>>国内不少软件在安装的时候，都会偷偷摸摸的把自己的root CA装到用户电脑里面去。
这样只会影响到安装了那些软件的用户吧，其它人没影响吧？
关键是你怎么弄到sohu 的管理员邮箱密码的？
吴洪声
September 29th, 2009 at 3:13 pm

我可没说我弄到sohu管理员邮箱的密码，我这是光明正大注册回来的。具体细节就不谈了
unixhater
September 29th, 2009 at 3:24 pm

嗯，明白了，证书提供商没有对邮箱进行验证，看来这是一个漏洞。
DF
September 29th, 2009 at 3:27 pm

漂亮的劫持，但这里有三个问题：
1. sohu让你注册了可用于验证的邮箱；这是sohu的严重漏洞。
2. PositiveSSL给了你过多的email选择（还是Comodo，mozilla那次也是他们）
3. 一旦被OCSP认定是非法证书，它立马就无效了。
这些都不是SSL协议的错。

---

讨论：http://j.mp/P2sQ6 http://j.mp/ClNDm http://j.mp/10UcNK

1. SSL 可以被欺骗，关键是用户缺乏安全常识，而不是监听>@samwu@jchirpcn 其实不管什么做法，最终目的已经达到，就是ssl绝对是可以被截取监听 的。至于截获邮件，方法有很多，从简单的到复杂的都有，比如在路由上截获邮件，又比如同网段内arp欺骗，等等等等，就不具体探讨了35 minutes ago from web
2. >@samwu SSL窃听攻击实操 http://bit.ly/18hUoN 图文并茂，step by step的教你玩ssl劫持35 minutes ago from web

[wanghx]

吴洪声所说的攻击方法可以窃听通信内容[3]。漏洞不在 SSL，而是在获取证书的 email 验证方式，sohu 允许注册管理员帐号，用户没有检验证书的习惯。 >@jchirpcn @samwu @wx8600 又解包不了内容，只能看到源地址和目的地址。

我奇怪的是，一个这么关心安全的技术人员，却在他们自己的网站[1]上采用中共国的证书颁发机构[2]颁发的证书，这不是自找漏洞么？且，如果很多人用他 们的 DNS，也意味着将极大的安全风险交给了这家公司。

我慎重建议各位不要用 dnspod.com, globalssl.cn。所有域名解析的数据，也就是访问记录，dnspod.com 都会取得。这些中共国的数字证书颁发机构，也是随时可以配合黑帮伪造证书的。

[1] https://www.dnspod.com/
[2] http://www.globalssl.cn/
[3] 吴洪声 SSL窃听攻击实操 https://groups.google.com/group/lihlii/browse_thread/thread/a8307a015a32c73f

---

[wanghx]

虽然不是 SSL 本身的漏洞，但是大多数针对应用软件设计缺陷，用户行为，软件
配置漏洞的攻击都是非常有效的。让非专业用户知道采用了 SSL 并不等于保证了
安全，知道比不知道好 >@jchirpcn 我当然看懂了。但是说ssl是可以被监听的这
句话是危言耸听，不正确的。

[wanghx]

http://www.williamlong.info/archives/1942.html
2009-9-30 16:8:10
解决SSL攻击的方法

　　SSL的窃听和安全 最近颇受关注，吴洪声提出了一种 SSL窃听攻击的思路，主要是利用了CA签发证书的一个重大缺陷：只验证目标网站的域名信箱即可签发该网站的证书，因此，只要搞到目标网站的一个信箱，就 可以窃取到这个域名的SSL证书。

　　因此，大多数免费邮 箱或公司邮箱的SSL证书都存在网站SSL证书被窃取的可能性，Gmail由于使用mail.google.com而不是www.gmail.com，因 此得以幸免于难。然而，有权使用google.com的Google公司的员工依然有可能获取google.com的SSL证书，一旦该证书被用于大规模 的域名劫持，后果 不堪设想。

　　如果想要避免这种 SSL证书窃取，CA需要修改目前的签发流程，即在签发前需要验证申请者对于该网站具有管理权限，例如，在网站的首页增加一小段隐藏代码，或者在网站上传 一个指定的HTML文件，这样，只有真正的网站拥有者才能做这样的操作，非法窃取者即使有了该域名的邮件，也无法获取该域名的证书。

　　当然，从根本上讲， 这个攻击并非对SSL安全协议本身的攻击，只是对其发行机构的攻击，SSL协议目前来说还是安全可靠的。

　　名词注释：SSL

　　安全套接字层 （Secure Sockets Layer，SSL） 是一套提供身份验证、保密性和数据完整性的加密技术。SSL 最常用来在 Web 浏览器和 Web 服务器之间建立安全通信通道，用以保障在 Internet 上数据传输之安全，SSL 利用数据加密技术，确保数据在网络上之传输过程中不会被截取及窃听，它也可以在客户端应用程序和 Web 服务之间使用。

原创文章如转载，请注明：转载自月光博客 [ http://www.williamlong.info/ ] 
本文链接地址：http://www.williamlong.info/archives/1942.html

---

 2.老胡
威廉龙不如破解个Google的ssl看看，保管轰动！
williamlong 于 2009-9-30 16:14:47 回复
我没有google.com的信箱啊。
unixhater 于 2009-9-30 16:56:19 回复
就算有了ssl证书又能怎样，除了ZF谁能劫持别人的网站？
2009-9-30 16:13:48   回复该留言
◇ 3.少爷
这么危险？不过我不用SSL。
2009-9-30 16:51:24   回复该留言
◇ 4.评论
有没有搞错，只要服务器的私钥不泄漏，其他人去另外签个证书有麻用？
证书是交钱就能签的
2009-9-30 16:58:45   回复该留言
◇ 5.探客
CNGOV
CA+劫持都可以做
2009-9-30 17:01:55   回复该留言
◇ 6.阿东
SSL这个进入银行系统时好像就会提示。。安全保密。。
不会这个也有功击。。那网上银行不是危险
2009-9-30 17:03:30   回复该留言
◇ 7.评论
另外签个证书也不能代替这个网站使用中的公钥和私钥
2009-9-30 17:03:34   回复该留言
◇ 8.jjyy
真正的漏洞还是中间人攻击吧
2009-9-30 17:10:43   回复该留言
◇ 9.Jacse
SSL购买倒是不贵，私钥不能泄露吧。
2009-9-30 17:13:23   回复该留言
◇ 10.olneeds
8，9 点钟的太阳炫彩夺目挂在高空，像向世人示耀它的光辉。早上，下了巴士，我眯着一双夹缝的细眼快步往公司方向赶，来不及偷窥刚才走过的摩登美女。
还在打卡的时候，丽就欣然嬉笑的向我打眼色：“早上看到秦美玲吗？ 今天装束得好时尚耶，戴着太阳眼镜，好ing呀！。” 这时秦美玲端着咖啡杯经过，婉尔一笑：“你们是说感觉我今天很不一样？ 呵呵。”“我还是穿平时的普通衣服，只是戴了一款太阳眼镜， 太阳大的时候可以保护眼睛，又可以搭配衣服。” “最惊喜的是我花了一元钱买的。” 秦美玲临走的时候还不忘向我们丢下炫耀的一句。
丽是出了名的淘友，一听有实惠的美物可是馋眼的跟在秦美玲 ×股后面去打探情况去了。原来是OL白领购物网站 做太阳眼镜“一抢一”活动，快看公告。我们急急忙忙的要到网址，按着网站上提示的步骤下了单。 办公室一群姐妹花 闻者有份，人手一副。
今早一到公司，丽的姐妹帮又在开闹了，原来昨天的眼镜已经收到，大家正在分物呢。我也跑去抢夺了一副，打开精美的包装盒一看，眼镜的镜片平整透晰，框架弧 度设计圆滑 ，试戴上之后也轻便舒适，没有压迫的感觉。令我爱不释手。
我心里暗自抿笑起来，这个周末逛街就穿白色裙子，配上这副太阳眼镜。肯定突出明星气质不少。惹来不少回头率让我那个呆呆的男朋友醋意大发吧。
2009-9-30 17:30:02   回复该留言
◇ 11.kevin
听起来挺玄的。不过看不懂。
2009-9-30 17:41:16   回复该留言
◇ 12.Eeffee
网上没有安全的了？
2009-9-30 18:35:12   回复该留言
◇ 13.xioubin
最近很和谐，大家留言小心点
2009-9-30 18:53:21   回复该留言
◇ 14.星光居士
最坚固的堡垒都是从内部攻破的。
2009-9-30 19:03:48   回复该留言
◇ 15.LouisHan
我国在这方面的技术总是世界领先的
zyoooo.com 于 2009-9-30 20:06:09 回复
还是你说得牛！！呵呵。
2009-9-30 19:57:27   回复该留言
◇ 16.麦圆
“例如，在网站的首页增加一小段隐藏代码，或者在网站上传一个指定的HTML文件，这样，只有真正的网站拥有者才能做这样的操作，非法窃取者即使有了该域 名的邮件，也无法获取该域名的证书。”——这样话博客提供商和免费空间指定域名提供商也可能被偷换证书了。再说，如果收取邮件的服务器在境内，只要有能力 置换通信内容的机构，也有能力假冒邮件接收服务器。所以归根结底，只要G*W在，一切都可以虚构。
2009-9-30 20:16:50   回复该留言
◇ 17.sweetsea
网络安全防不胜防！
2009-9-30 20:26:52   回复该留言
◇ 18.zhiwu88
要是能详细点就好了，只是大概说了点，估计发行机构知道了也未必懂改正！
2009-9-30 20:44:08   回复该留言
◇ 19.三脚猫
没有绝对安全的东西，再安全的东西只是时间的问题。。
2009-9-30 21:05:30   回复该留言
◇ 20.NBA
看不懂............
2009-9-30 21:40:08   回复该留言
◇ 21.南靖男
“在网站的首页增加一小段隐藏代码，或者在网站上传一个指定的HTML文件”的方式也不安全的。
能控制网关恶意伪造这些代码和指定的html请求有效就可以了。
当然，邮箱验证就更简单，直接拦截就是了。
相对而言，采用特别的二级域名CNAME指向另外一个特别的domain是比较安全。毕竟证书的发行商只要保证自己同互联网根域名解析服务器之间的通讯不 会被劫持，而不用担心访问其用户的指定数据遭到劫持。当然，另外一个条件就是用户能对自己的域名安全的操作，而不是被劫持。
2009-9-30 22:27:54   回复该留言

---

[RUI LIU]

关于SSL攻击,我认为并不应该提到一个高度的关注上来.大家已经知道SSL攻击并非SSL加密体系遭到破解,只是攻击者利用了其中的一个小漏洞(张冠李戴,替换证书),这是一种雕虫小计,俗话来讲就是办假证.这只需要使用者稍微注意一下,学习一下有关证书的知识就行了,完全不必恐慌.至于中共有没有可能干这种事呢? 可能性是有的,但不会很高,因为攻击者自身也明白,造假证是一种很卑劣的行为,攻击者首先要承担心理上的折磨,其次还要考虑到一旦丑行败露,被媒体公布出去自己的脸面问题,中国人是最要面子的,所以中共造假证欺骗用户的可能性比较小.比较实际的做法是,他们对内容审查还是比较倾向于实际解密,这需要技术上的保证,一般来说在短时间内是很难做到的.

 

而且,由于多层加密软件TOR的出现,就算是不用SSL连接中共也无法破解.TOR可能是在互联网封锁上面中共遇到的最棘手的问题.从技术层面上讲, 中共现在有华为牵头的IT公司帮着研发超级路由器,防火墙,但是从IT加密产业上看,美国是远远领先于中国的,中国现在只能用一些低级的手段,比如直接封IP地址来封锁TOR,(相信华为搞出来的防火墙在这个功能上是可扩充的,只要需要,被封IP地址容量可以有无限多)这个方法目前看来取得了一定的效果,但是TOR使用Bridge后,仍然能够存活.但毕竟说来,使用bridge之后,连接速度会大幅降低,使用效能大致上只有原来的20%-30%,所以使用Bridge来连接,总得说来仍然不理想. TOR被封锁IP是他们的设计者的一个策略失误,因为在GUI里RELAY的大批IP地址可以轻易被获取,就算一个没有任何网络知识的人,他也可以轻松地将TOR封锁(只要他有操作GFW的权限),正如TOR的创始人说的那样,"这个软件主要目的是为了匿名,而不是对抗封锁",但现在封锁的这一天终于来了,我已经给TOR的设计者发了邮件,请他们注意这一问题,"要将保护Relay作为首要任务",相信TOR会注意到这一问题并对此作出改进,那么中共想封掉TOR就没那么容易了.直接封IP地址是网络使用者最卑鄙的行为之一,粗暴侵犯网络使用自由,与互联网创建的本意背道而驰,而且没有任何技术含量!

----- Original Message -----

From: wanghx

To: lih...@googlegroups.com

Sent: Wednesday, September 30, 2009 11:53 PM

Subject: 月光博客: 解决SSL攻击的方法

http://www.williamlong.info/archives/1942.html
2009-9-30 16:8:10
解决SSL攻击的方法

　　SSL的窃听和安全最近颇受关注，吴洪声提出了一种 SSL窃听攻击的思路，主要是利用了CA签发证书的一个重大缺陷：只验证目标网站的域名信箱即可签发该网站的证书，因此，只要搞到目标网站的一个信箱，就可以窃取到这个域名的SSL证书。

[wanghx]

你居然说这个党国是要面子的？天啊。他们不是什么中国人，要党性没人性。人都不是，谈何中国人呢？

至于 SSL 证书欺诈，我认为非常有效，绝大部分用户都不会发现，而且现有的浏览器都没有充分考虑这一漏洞。这是很大的设计失误。

2009/9/30 RUI LIU <ray....@gmail.com>

关于SSL攻击,我认为并不应该提到一个高度的关注上来.大家已经知道SSL攻击并非SSL加密体系遭到破解,只是攻击者利用了其中的一个小漏洞(张冠李戴,替换证书),这是一种雕虫小计,俗话来讲就是办假证.这只需要使用者稍微注意一下,学习一下有关证书的知识就行了,完全不必恐慌.至于中共有没有可能干这种事呢? 可能性是有的,但不会很高,因为攻击者自身也明白,造假证是一种很卑劣的行为,攻击者首先要承担心理上的折磨,其次还要考虑到一旦丑行败露,被媒体公布出去自己的脸面问题,中国人是最要面子的,所以中共造假证欺骗用户的可能性比较小.比较实际的做法是,他们对内容审查还是比较倾向于实际解密,这需要技术上的保证,一般来说在短时间内是很难做到的.

[wanghx]

各位注意：这个 ray....@gmail.com 是一只网狗特务[1]。

他还联系 tor 项目组负责人了，很危险，肯定是想去套取情报。

明明已经有论文报道，在 tor 网络上截获大量粗心用户的帐号密码，此狗还试图误导视听，说“TOR的出现,就算是不用SSL连接中共也无法破解”。从他对 tor 的突破封锁和安全性的虚假吹捧，可以看出黑帮狗主子很可能会在 tor 网络上进行窃听。

[1] 为什么说这是一只网狗呢 https://groups.google.com/group/lihlii/browse_frm/thread/3cfb27e3f6de5b59

[2] 如何做到窃听SSL的内容的？ https://groups.google.com/group/lihlii/browse_frm/thread/a8307a015a32c73f

2009/9/30 RUI LIU <ray....@gmail.com>