来源:http://huaidan.org/archives/1493.html
QQ网站登录处没有使用https进行加密,而是采用了RSA非对称加密来保护传输过程中的
密码以及敏感信息的安全性。 QQ是在javascript中实现整个过程的。这个想法非常新
颖,详细可以参考云舒写过的 《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则提出来一个更邪恶的想法(顺便在这里祝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能越做越好。
QQ网站登录处没有使用https进行加密,而是采用了RSA非对称加密来保护传输过程中的
密码以及敏感信息的安全性。 QQ是在javascript中实现整个过程的。这个想法非常新
颖,详细可以参考云舒写过的 《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则提出来一个更邪恶的想法(顺便在这里祝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能越做越好。