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

Re: Mismatch between renegotiation reported vs functional

[Matt Caswell]

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/ 



Thanks!
--
Shaun Robbins