我在客户端和服务器上使用OpenSSL 1.0.0e进行测试,但在测试安全重新协商时收到错误消息。
$ openssl s_client -connect 192.168.1.99:443 -tls1
...
Secure Renegotiation IS supported
...
R
RENEGOTIATING
140501522626208:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:591:
答案 0 :(得分:4)
为了更详细地了解这个问题,这里有一些相关的信息:
The official description:
TLS协议,SSL协议3.0以及可能更早的版本,如Microsoft Internet Information Services(IIS)7.0,Apache HTTP Server 2.2.14及更早版本中的mod_ssl,0.9.8l之前的OpenSSL,GnuTLS 2.8.5早些时候,Mozilla网络安全服务(NSS)3.12.4及更早版本,多个思科产品和其他产品没有正确地将重新协商握手与现有连接相关联,这允许中间人攻击者将数据插入HTTPS会话,以及可能受TLS或SSL保护的其他类型的会话,通过发送未经身份验证的请求,该请求在后重新协商上下文中由服务器追溯处理,与“明文注入”攻击相关,即“Project Mogul”问题。
Details about the CVE and affected versions:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3555
A thorough explanation of the vulnerability, its symptoms and possible solutions:
http://www.g-sec.lu/practicaltls.pdf
因此,为了总结漏洞要求,TLS或SSLv3连接易受攻击的先决条件是:
1服务器在连接过程中和初始握手后确认并接受完整的TLS重新协商
和
2服务器假定两个TLS会话都与同一客户端协商
和
3服务器将两个会话视为一个会话,并将它们合并到应用程序层
话虽如此,根据上述要求,对端口443上的服务器进行的测试表明不允许重新协商:
弱势服务器的一般示例
Openssl s_client –connect yourserver.com:443
GET / HTTP/1.0
Host:yourserver.com
R (Triggers renegotiation – if this works, the server accepts enegotiations
within an existing TLS session Req. #1)
CRLF
<server responds with content> (server merged both sessions Req. #2)
受保护的服务器
Openssl s_client –connect yourserver.com:443
R (Triggers renegotiation)
2860:error:1409444C:SSL routines:SSL3_READ_BYTES:tlsv1 alert no
renegotiation:./ ssl/s3_pkt.c:1053:SSL alert number 100
干杯!