详解SSL renegotiation攻击[网络技术]

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