英文不错的朋友可以参看我英文博客上的原文 。该攻击利用了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漏洞相比！
