QQ網(wǎng)站登錄處沒有使用https進行加密，而是采用了RSA非對稱加密來保護傳輸過程中的密碼以及敏感信息的安全性。 QQ是在javascript中實現(xiàn)整個過程的。這個想法非常新穎，但是也是存在嚴重缺陷的。如果被黑客利用，則可能被捕獲明文密碼。
分析報告如下：

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

這個想法非常新穎，詳細可以參考云舒寫過的 《RSA非對稱加密的一些非常規(guī)應(yīng)用》，地址為http://www.icylife.net/yunshu/show.php?id=471

這個原理簡單描述為下：
1. 在server端生成一對RSA密鑰，包括public key 和 private key
2. public key傳輸給客戶端瀏覽器， 客戶端瀏覽器用public key加密敏感數(shù)據(jù)，比如密碼；加密后的密文傳回給server，然后server用 private key解密。
3. 注意private key只保存在server端，而public key則分發(fā)給所有人。 由于 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加密敏感數(shù)據(jù)，比如密碼，并將加密后的數(shù)據(jù)傳輸給攻擊者
5. 攻擊者用fake private key解密，獲得明文密碼等
6. 攻擊者用server的public key加密明文數(shù)據(jù)，并傳送給server

整個過程中不會出現(xiàn)任何提示，而用戶的明文數(shù)據(jù)則被竊取了！

而luoluo則提出來一個更邪惡的想法（順便在這里祝luoluo今天生日快樂！），他提出可以直接將加密的介質(zhì)修改。

比如，如果是用js在做加密，則修改js，如果是用flash或java applert做加密，則替換flash或applet，直接去掉這種加密機制，捕獲明文密碼。

那么為什么說https是不可替代的呢？ 因為當實施中間人攻擊的時候，瀏覽器會提示證書已改變（具體參考云舒的關(guān)于https安全性的文章），這種機制是內(nèi)建在瀏覽器里的，攻擊者無力改變它。所以這種報警是非常有意義的。

而如果像QQ一樣使用js進行RSA加密傳輸，實施中間人攻擊的時候，是不會有任何提示的，一切都會在用戶不知情的情況下發(fā)生。

這種情況和以前windows的RDP中間人攻擊情況一樣: 當使用3389端口的rdp協(xié)議登錄時候，證書改變的時候沒有任何提示。

而相對設(shè)計比較安全的ssh協(xié)議，ssl協(xié)議等，則都會針對證書改變做出提示，防止中間人攻擊。

所 以，QQ的這個方案只能保護傳輸過程中一般的sniffer攻擊，但是考慮到當今網(wǎng)絡(luò)環(huán)境下，大部分的sniffer都是基于arp欺騙的，所以這種保護 機制其實是非常脆弱的。它只能對抗目前已知的arp sniffer軟件，而對專門開發(fā)的替換關(guān)鍵字的軟件，則無法有效防御。一旦這種專門針對QQ網(wǎng)站登錄的sniffer軟件被開發(fā)出來并且提供下載，災難 就不遠了。

不過這個方案還是有積極意義的，除去不能抵抗中間人攻擊的缺陷外，其他方面都比較完美，特別是成本低廉。如果與https結(jié)合使用來防止中間人攻擊的話，整個方案就更完美了。

之前曾與朋友戲言QQ是否會因為我這一篇文章而多花費幾百萬的經(jīng)費去購買https證書和https硬件加速服務(wù)器，現(xiàn)在讓我們拭目以待，看看QQ是否是真正的用戶至上。