On 25/03/2021 21:59, Shaun Robbins wrote:
While trying to disable renegotiation the response from openssl reads
"Secure Renegotiation IS supported" even though renegotiation is failing.
Up until 2009 we just had "Renegotiation" as a concept. Then along came
a man-in-the-middle attack on such renegotiation. For example see:
https://blog.qualys.com/product-tech/2009/11/05/ssl-and-tls-authentication-gap-vulnerability-discovered
The problem was a fundamental flaw in the design of renegotiation. So
then RFC5746 was written in order to address this problem.
Clients/Servers that support RFC5746 are said to support "Secure
Renegotiation".
Support for secure renegotiation can be indicated via the use of a
special ciphersuite, or through the use of extensions.
The "Secure Renegotiation IS supported" message means that both peers
have indicated support for RFC5746. This is entirely independent of
whether a server will actually *allow* any renegotiation at all. In fact
it is impossible for the client to know this. The server does not
indicate it in any way.
So the problem here is a misunderstanding about what this message
*means*, i.e. it means both peers have indicated support for RFC5746
(known as "secure renegotiation"). It doesn't tell you whether
renegotiation will actually work.
Matt
OpenSSL Config:
SSL_set_options(ssl_conn, SSL_OP_NO_RENEGOTIATION);
] $openssl s_client -connect localhost:443 -tls1_2
[SNIP]
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
*Secure Renegotiation IS supported
*Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
[SNIP]
---
HEAD / HTTP/1.1
R
RENEGOTIATING
139845827855680:error:14094153:SSL routines:ssl3_read_bytes:no
renegotiation:../ssl/record/rec_layer_s3.c:1560:
This article refers to this same problem with some screen shots under
section "Eliminating a false positive":
https://www.mcafee.com/blogs/enterprise/tips-securing-ssl-renegotiation/
<https://www.mcafee.com/blogs/enterprise/tips-securing-ssl-renegotiation/>
Thanks!
--
Shaun Robbins
