QQ网站登录的RSA加密传输缺陷分析
  

QQ网站登录处没有使用https进行加密，而是采用了RSA非对称加密来保护传输过程中的密码以及敏感信息的安全性。 QQ是在javascript中实现整个过程的。这个想法非常新颖，但是也是存在严重缺陷的。如果被黑客利用，则可能被捕获明文密码。
分析报告如下：


Author: axis
Date: 2007-11-23
Team: http://www.ph4nt0m.org  (http://pstgroup.blogspot.com)
Corp: Alibaba B2B Corp / Infomation Security

这个想法非常新颖，详细可以参考云舒写过的《RSA非对称加密的一些非常规应用》，地址为http://www.icylife.net/yunshu/show.php?id=471

这个原理简单描述为下：
1. 在server端生成一对RSA密钥，包括public key 和 private key
2. public key传输给客户端浏览器， 客户端浏览器用public key加密敏感数据，比如密码；加密后的密文传回给server，然后server用 private key解密。
3. 注意private key只保存在server端，而public key则分发给所有人。由于 private key只有server知道，所以密文即使被截获了，也无法解开。

这个解决方案其实还是非常好的，至少他防住了大部分的攻击，但是为什么说它是无法替代https，是有缺陷的呢？

因为这个方案无法防止中间人攻击（man-in-the-middle）。

攻击过程如下：
1. 攻击者通过MIM（比如arp欺骗等）劫持server与客户端浏览器之间的http包
2. 攻击者生成一对伪造的RSA密钥： fake public key/fake private key
3. 攻击者将js文件中的public key替换为fake public key，并传输给客户端浏览器
4. 客户端浏览器用 fake public key加密敏感数据，比如密码，并将加密后的数据传输给攻击者
5. 攻击者用fake private key解密，获得明文密码等
6. 攻击者用server的public key加密明文数据，并传送给server

整个过程中不会出现任何提示，而用户的明文数据则被窃取了！

而luoluo则提出来一个更邪恶的想法，他提出可以直接将加密的介质修改。

比如，如果是用js在做加密，则修改js，如果是用flash或java applert做加密，则替换flash或applet，直接去掉这种加密机制，捕获明文密码。

那么为什么说https是不可替代的呢？因为当实施中间人攻击的时候，浏览器会提示证书已改变（具体参考云舒的关于https安全性的文章），这种机制是内建在浏览器里的，攻击者无力改变它。所以这种报警是非常有意义的。

而如果像QQ一样使用js进行RSA加密传输，实施中间人攻击的时候，是不会有任何提示的，一切都会在用户不知情的情况下发生。

这种情况和以前windows的RDP中间人攻击情况一样: 当使用3389端口的rdp协议登录时候，证书改变的时候没有任何提示。

而相对设计比较安全的ssh协议，ssl协议等，则都会针对证书改变做出提示，防止中间人攻击。

所以，QQ的这个方案只能保护传输过程中一般的sniffer攻击，但是考虑到当今网络环境下，大部分的sniffer都是基于arp欺骗的，所以这种保护机制其实是非常脆弱的。它只能对抗目前已知的arp sniffer软件，而对专门开发的替换关键字的软件，则无法有效防御。一旦这种专门针对QQ网站登录的sniffer软件被开发出来并且提供下载，灾难就不远了。

不过这个方案还是有积极意义的，除去不能抵抗中间人攻击的缺陷外，其他方面都比较完美，特别是成本低廉。如果与https结合使用来防止中间人攻击的话，整个方案就更完美了。

之前曾与朋友戏言QQ是否会因为我这一篇文章而多花费几百万的经费去购买https证书和https硬件加速服务器，现在让我们拭目以待，看看QQ是否是真正的用户至上。

希望QQ能越做越好