openssl: What's the error "unsafe legacy renegotiation disabled" really mean?

Hello,

when executing the command below I’ve the following output:

Command

openssl s_client -connect somehost.com.br:443 -tls1_2

Output

CONNECTED(00000003)
804B1EBA547F0000:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:../ssl/statem/extensions.c:879:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 3058 bytes and written 231 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1687864660
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---

As you can see in the output, Secure Renegotiation IS NOT supported, but the error says something about unsafe legacy renegotiation. What it means?

A) That openssl cannot call this host because Secure Renegotiation IS NOT supported B) That openssl cannot call this host because it’s using the Legacy Renegotiation

Assuming the answer is B, if they disable Legacy Renegotiation will the first command work?

P.S¹: I’m using OpenSSL 3.0.2. P.S²: I know that if I add the parameter -legacy_renegotation it will work, I just need to understand the failure reason behind the first command.

About this issue

Original URL
State: closed
Created a year ago
Comments: 18 (10 by maintainers)

Most upvoted comments

How can I turn this off?

Try this (I’ve not tested this):

Create a config file that looks like this:

openssl_conf = default_conf

[ default_conf ]

ssl_conf = ssl_sect

[ssl_sect]

system_default = ssl_default_sect

[ssl_default_sect]

Options = UnsafeLegacyRenegotiation

Run pip using that OpenSSL config file:

OPENSSL_CONF=/path/to/the/config/file/above.cnf pip ....whatever...

mattcaswell on Nov 14, 2023

Looks like you need to update to 10.2.5 or later: https://docs.paloaltonetworks.com/pan-os/10-2/pan-os-release-notes/pan-os-10-2-5-known-and-addressed-issues/pan-os-10-2-5-addressed-issues

PAN-184630 | Fixed an issue where TLS clients, such as those using OpenSSL 3.0, enforced the TLS renegotiation extension (RFC 5746).

davidben on Nov 14, 2023

What I wrote above was not meant to be fully serious. And by TLS-1.2 being obsolete I meant it will be marked as obsolete by IETF RFC the same way as 1.1 and 1.0 is. I did not mean by that it won’t be used on public internet at all.

t8m on Nov 15, 2023

https://github.com/openssl/openssl/issues/21296#issuecomment-1810043699 already answered what to do in the short term, no?

It is understandably frustrating when a deployment gets hit by changes to a default. At the same time, it takes changes like this to plug security risks. Here, clients cannot be sure they’re protected against the renegotiation bug without enforcing the extension is present. As much as it’s bad to break deployments that are (13 years!) behind, it’s also bad to leave the vast majority of correct deployments unprotected.

If there were a mechanism to phone up every TLS deployment and remind them to apply some 13-year-old fix before making the change, that would be amazing. Sadly, there isn’t. Absent that, the best one can do is wait until the balance has shifted and flip the default.

That will invariably break the stragglers, like Palo Alto Networks here, that didn’t get the memo. (Evidently PAN, despite shipping a TLS product, have not paying attention to industry-wide developments in TLS for the past 13 years…) So you provide a short-term mechanism to turn it back off. But since the goal is, ultimately, to get everyone into the safe configuration, the response to such an incident is always two fold:

Here is the knob to you can toggle to fix it in the short term (@mattcaswell’s response)
Here is what your server should be doing to avoid needing the knob in the long term (my response)

Both tracks are important. Yes, it’s expected the long-term fix will take time. That’s why the short-term fix is available. But all the more reason to get the ball rolling on the long-term fix too. I asked for the vendor information above to do just that:

If it happened that PAN hadn’t provided a fix yet, I would have reached out to them to get them to fix it
It turned out they had provided a fix, so hopefully now that you know it’s 10.2.5, that will make the long-term fix easier for your deployment

(I should note that I’m not speaking on behalf of OpenSSL here. But I’m often involved in such decisions in Chrome, so I thought I’d elaborate a bit on how these go, and why I tried to identify buggy product. Indeed I hope we can require this extension in Chrome in the future. Though, with the current numbers, I think I need to do some more outreach before it’s viable on the web, regrettably.)

davidben on Nov 14, 2023

TLSv1.2 (and earlier) support the concept of renegotiation. In 2009 (i.e. after the TLSv1.2 RFC was published), a flaw was discovered with how renegotiation works that could lead to an attack. After the attack was discovered a fix was deployed to all TLS libraries. In order for the fixed version of renegotiation to work both the client and the server need to support it.

The original (unfixed) version of renegotiation is known as “unsafe legacy renegotiation” in OpenSSL. The fixed version is known as “secure renegotiation”. So either a peer does not have the fix, in which case it will be using “unsafe legacy renegotiation”, or it does have the fix in which case it will be using “secure renegotation”.

So your (A) and (B) are actually the same thing.

If the server starts supporting secure renegotiation then the command will start to work.

mattcaswell on Jun 27, 2023