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