英文不錯的朋友可以參看我英文部落格上的原文 。該攻擊利用了SSL協議renegotiation的漏洞，允許攻擊者以中間人攻擊的方式在通訊的起始部分插入任意的選擇明文。以下假設你對SSL/TLS的工作方式，尤其是renegotiation比較熟悉，並且對HTTP有基本的瞭解。

第一個場景：當要求客戶證書時
在理想情況下，伺服器會在第一次和客戶握手時要求其提供證書。但在現實中，出於種種原因，客戶證書僅在必要時（如請求一個要求提供客戶證書的資源）才被請求，會導致伺服器發起一次renegotiation。不幸的是，HTTP協議無法通知客戶端在renegotiation後重新提交請求，因此伺服器會在renegotiation後自動回覆上一次請求。

該攻擊可表示如下：

1）客戶請求握手，被攻擊者劫持；

2）攻擊者和伺服器建立通訊；

3）攻擊者向伺服器請求某個需要提供客戶證書的資源；

4）伺服器要求renegotiation；

5）攻擊者通過轉發，讓客戶和伺服器建立連結；

6）伺服器向客戶傳送攻擊者在第3步請求的資源。

現在，客戶端得到了並非其請求的資料......

第二個場景：伺服器使用了不同的加密演算法

出於種種考慮，某些站點使用不同的加密演算法保護不同的資源。當客戶請求的資源被不同加密演算法保護時，伺服器會要求進行renegotiation。看下面這個例子。
攻擊者向伺服器傳送如下請求：
GET /index.html HTTP/1.1
Host: server_address
Connection: keep-alive

GET /evil.html HTTP/1.1
x-ignore:

注意，這裡的x-ignore後沒有換行符！第二個請求會在renegotiation後被客戶補充：
GET /good.html HTTP/1.1
Host: server_address
Cookie: client_cookie

不幸的是，伺服器會儲存renegotiation前的請求，並把客戶的請求錯誤的理解成：
GET /evil.html HTTP/1.1
x-ignore: GET /good.html HTTP/1.1
Host: server_address
Cookie: client_cookie

這樣，伺服器會返回/evil.html 而非/good.html ......

第三個場景：客戶主動發起renegotiation
由於SSL/TLS也允許客戶發起renegotiation，因此這個場景是最危險的一個！看這個例子：
1）攻擊者向伺服器傳送請求：
GET /evil.html HTTP/1.1
R
x-ignore:

這裡，R 會導致renegotiation，而沒有換行符的x-ignore: 則會被伺服器快取。

2）攻擊者通過訊息轉發，“幫助”客戶和伺服器建立連線。

3）客戶向伺服器傳送請求：
GET /index.html HTTP/1.1

Host: server_address
Connection: keep-alive

但由於伺服器的快取機制，其將客戶請求錯誤的理解為：
GET /evil.html HTTP/1.1
R
x-ignore: GET /index.html HTTP/1.1
Host: server_address
Connection: keep-alive

因此，伺服器會返回/evil.html 而非客戶請求的/indes.html 。

簡單的說，這幾種攻擊都是攻擊者通過發起renegotiation，利用SSL和上層協議間的協調不一致性，在客戶和伺服器會話開始前插入任意的明文。我想這個攻擊還是比較容易理解和實現的，對吧？此外，研究人員已經提交 了一個草案以修復此漏洞。該修復是在發起renegotiation時，在HELLO訊息中加入上次FINISHED訊息中的驗證資料，以連線兩次會話。但是，該草案會修改TLS協議本身，部署成本較高。

最後，我想再次提醒 大家，這個攻擊是針對SSL/TLS協議本身，而非某個具體的實現，危害程度完全可以和去年發現的DNS和BGP漏洞相比！