OpenSSL 安全重新协商失败 [英] OpenSSL secure renegotiation failed

问题描述

我在客户端和服务器上都使用 OpenSSL 1.0.0e 进行测试，但在测试安全重新协商时收到错误消息.

I was using OpenSSL 1.0.0e on both client and server to do the test, but I got an error message when testing secure renegotiation.

$ 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:

推荐答案

为了更详细地了解这个问题，这里有一些相关信息:

To understand the issue in a bit more detail here is some relevant information:

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 及更早版本、多个 Cisco 产品和其他产品未将重新协商握手与现有连接正确关联，这允许中间人攻击者将数据插入 HTTPS会话，以及受 TLS 或 SSL 保护的其他类型的会话，通过发送未经身份验证的请求，该请求由服务器在重新协商后的上下文中追溯处理，与明文注入"攻击相关，也就是项目大亨"问题.

The TLS protocol, and the SSL protocol 3.0 and possibly earlier, as used in Microsoft Internet Information Services (IIS) 7.0, mod_ssl in the Apache HTTP Server 2.2.14 and earlier, OpenSSL before 0.9.8l, GnuTLS 2.8.5 and earlier, Mozilla Network Security Services (NSS) 3.12.4 and earlier, multiple Cisco products, and other products, does not properly associate renegotiation handshakes with an existing connection, which allows man-in-the-middle attackers to insert data into HTTPS sessions, and possibly other types of sessions protected by TLS or SSL, by sending an unauthenticated request that is processed retroactively by a server in a post-renegotiation context, related to a "plaintext injection" attack, aka the "Project Mogul" issue.

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 连接易受攻击的先决条件是:

So to sum-up the vulnerability requirements, the preconditions for a TLS or SSLv3 connection to be vulnerable are:

1 服务器在连接中间和初始握手后确认并接受完整的 TLS 重新协商

1 The server acknowledges and accepts full TLS renegotiations in the middle of a connection and after the initial handshake

和

2 服务器假定两个 TLS 会话都是与同一个客户端协商的

2 The server assumes that both TLS sessions were negotiated with the same client

和

3 服务器将两个会话视为一个，并在应用层合并它们

3 The server treats both sessions as one and merges them at the application layer

话虽如此，根据上述要求，对端口 443 上的服务器进行的测试表明不允许重新协商:

That being said, based on the requirements above a test against the server on port 443 shows that renegotiation is not allowed:

易受攻击的服务器的通用示例

Generic Example Of A Vulnerable Server

    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

干杯！

这篇关于OpenSSL 安全重新协商失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！