Mismatch between renegotiation reported vs functional

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Mismatch between renegotiation reported vs functional

Shaun Robbins
While trying to disable renegotiation the response from openssl reads "Secure Renegotiation IS supported" even though renegotiation is failing. 

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


Thanks! 
--
Shaun Robbins
Reply | Threaded
Open this post in threaded view
|

Re: Mismatch between renegotiation reported vs functional

Matt Caswell-2


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
Reply | Threaded
Open this post in threaded view
|

Re: Mismatch between renegotiation reported vs functional

Shaun Robbins
Matt,

Thanks a ton for this intel and taking time to provide this answer! This is great backstory and information on what the message actually is telling me. 

Cheers and happy Friday! 

On Fri, Mar 26, 2021 at 5:19 AM Matt Caswell <[hidden email]> wrote:


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


--
--
Shaun Robbins