OpenSSL 安全重新协商失败
我在客户端和服务器上使用 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:
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:
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
要更详细地了解这个问题,这里有一些相关信息:
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 保护的其他类型的会话中由服务器在重新协商后上下文中追溯,与“明文注入”攻击(又名“Project Mogul”问题)相关。
因此,总结一下漏洞要求,TLS 或 SSLv3 连接易受攻击的先决条件是:
1 服务器在连接中间和初始握手之后确认并接受完整的 TLS 重新协商
,并且
2 服务器假设 TLS 和 SSLv3 连接均已启用。会话是与同一客户端协商的
,并且
3 服务器将两个会话视为一个会话,并在应用程序层将它们合并
也就是说,根据上述要求,在端口 443 上对服务器进行的测试显示:不允许重新协商:
易受攻击的服务器的通用示例
受保护的服务器
干杯!
To understand the issue in a bit more detail here is some relevant information:
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.
So to sum-up the vulnerability requirements, the preconditions for a TLS or SSLv3 connection to be vulnerable are:
1 The server acknowledges and accepts full TLS renegotiations in the middle of a connection and after the initial handshake
and
2 The server assumes that both TLS sessions were negotiated with the same client
and
3 The server treats both sessions as one and merges them at the application layer
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
Protected server
Cheers!