Disabling TLS Renegotiation and TLS Secure Renegotiation

[ranierimazili]

Hello,

I'm implementing Open Finance API's for brazilian ecosystem and the requirements are regulated by a central institution (Central Bank of Brazil).

One of the security requiments is:

3.5 The features "TLS Session Resumption" and "TLS Renegotiation" must be disabled

We asked the regulator(Central Bank of Brazil) if TLS Secure Renegotiation is included when they said TLS Renegotiation and they answered "yes", so we must also disable TLS Secure Renegotiation on our servers.

I've tried to disable TLS Secure Renegotiation chaging openssl.cnf options when checking the configuration against apache and nginx (that relys on openssl), but always without success. Everytime I try a command like below I'll see TLS Secure Renegotiation is still enabled.

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

I know that's possible to disable both features using appliances, like Citrix ADC, but I would like to see if it's also possible using only openssl configuration.

Thanks

[davidben]

I think you were given incorrect advice. Disabling "secure renegotiation" and disabling "renegotiation" are not the same thing. You do not want to disable "secure renegotiation".

Disabling "renegotiation" is a good idea because renegotiation is an extremely problematic feature. But having "secure renegotiation" show up in openssl s_client is very important and should not be disabled.

"Secure renegotiation" does not mean you support renegotiation. It merely means that you have applied the security fix in RFC 5746. It is important to support that extension even if you have disabled renegotiation, due to details of how the attack works. (The client can't know whether you've disabled renegotiation or not, so it needs to check for it always being present.) Indeed, if you were to disable that, your site may stop working with future clients that check for this security fix.

The problem here is just that the output of the command is confusing. To check whether renegotiation itself is disabled, you need the client to actually attempt a renegotiation and see that it failed. One way to do this is to send the "R" comment to openssl s_client. For example:

$ echo R | openssl s_client -connect www.google.com:443 -tls1_2
[...]
RENEGOTIATING
800B0B2E497F0000:error:0A00044C:SSL routines:ssl3_read_bytes:tlsv1 alert no renegotiation:../ssl/record/rec_layer_s3.c:1605:SSL alert number 100

This shows that www.google.com forbids client-initiated renegotiation. In OpenSSL, the option to disable renegotiation is SSL_OP_NO_RENEGOTIATION. Again, this will still show "secure renegotiation" in openssl s_client because that is talking about something else.

[ranierimazili]

Hi @davidben, thanks for you reply, just one more question.

Take a look at the output below

$ openssl s_client -connect somehost.com -tls1_2
CONNECTED(00000003)
80AB87CD377F0000: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: 1689213650
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---

At this output, Secure Renegotiation IS NOT supported.
Does it mean this host hasn't applied the RFC 5746 for sure?

When executing the command to test if renegotiation is enabled, it's also disabled:

$ echo R | openssl s_client -connect somehost.com:443 -tls1_2 -legacy_renegotiation
---
RENEGOTIATING
80EB263BF77F0000:error:0A00044C:SSL routines:ssl3_read_bytes:tlsv1 alert no renegotiation:../ssl/record/rec_layer_s3.c:1584:SSL alert number 100

Does it mean this host is under some risk even with renegotiation disabled?

Thanks

[mattcaswell]

Note that it is not possible to disable secure renegotiation in OpenSSL. An OpenSSL server will always attempt to negotiate it. It is possible to modify the behaviour of what happens if the peer does not support it.

80AB87CD377F0000:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:../ssl/statem/extensions.c:879:

The error message tells you that the client has aborted the connection attempt because the server does not support secure renegotiation and has not applied RFC5746.

This error is a good example of why you should not disable secure renegotiation. It is the default behaviour of an OpenSSL client to abort the connection if secure renegotiation has been disabled.

Does it mean this host is under some risk even with renegotiation disabled?

The problem here is not whether the server is at risk, but that the client does not know whether it is safe to communicate with the server. For this reason it is a bad idea to configure clients to ignore the lack of secure renegotiation support. Therefore you should NOT attempt to disable this support on the server (and you could not do so anyway with an unmodified OpenSSL).