BTW, a decent explanation of the implications of the UnsafeLegacyServerConnect option (which corresponds to SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION in code) is found in SSL_CTX_set_options(3ossl):
SECURE RENEGOTIATION
OpenSSL always attempts to use secure renegotiation as described in RFC5746. This counters the prefix attack
described in CVE-2009-3555 and elsewhere.
This attack has far reaching consequences which application writers should be aware of. In the description
below an implementation supporting secure renegotiation is referred to as patched. A server not supporting
secure renegotiation is referred to as unpatched.
The following sections describe the operations permitted by OpenSSL's secure renegotiation implementation.
[...]
Patched OpenSSL client and unpatched server
If the option SSL_OP_LEGACY_SERVER_CONNECT or SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION is set then initial
connections and renegotiation between patched OpenSSL clients and unpatched servers succeeds. If neither
option is set then initial connections to unpatched servers will fail.
Setting the option SSL_OP_LEGACY_SERVER_CONNECT has security implications; clients that are willing to
connect to servers that do not implement RFC 5746 secure renegotiation are subject to attacks such as
CVE-2009-3555.
OpenSSL client applications wishing to ensure they can connect to unpatched servers should always set
SSL_OP_LEGACY_SERVER_CONNECT
OpenSSL client applications that want to ensure they can not connect to unpatched servers (and thus avoid
any security issues) should always clear SSL_OP_LEGACY_SERVER_CONNECT using SSL_CTX_clear_options() or
SSL_clear_options().
The difference between the SSL_OP_LEGACY_SERVER_CONNECT and SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION options
is that SSL_OP_LEGACY_SERVER_CONNECT enables initial connections and secure renegotiation between OpenSSL
clients and unpatched servers only, while SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION allows initial
connections and renegotiation between OpenSSL and unpatched clients or servers.
Original Message:
Sent: Feb 28, 2024 04:58 AM
From: yrro
Subject: "unsafe legacy renegotiation disabled" errors from OpenSSL 3
It seems that newer versions of OpenSSL (as shipped in RHEL 9) are refusing to talk to my Instant 8.6.0.23 devices:
$ curl https://192.0.2.1:4343/curl: (35) OpenSSL/3.1.1: error:0A000152:SSL routines::unsafe legacy renegotiation disabled
In case anyone else is scratching their head over this, the workaround is to add the UnsafeLegacyServerConnect option, documented in SSL_CONF_cmd(3ossl), to your openssl.cnf file. Finding the right point in that file is quite difficult, but for RHEL 9, it needs to be added here:
[ crypto_policy ]# BEGIN LOCAL MODIFICATIONS# <https://bugzilla.redhat.com/show_bug.cgi?id=2072070># <https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/issues/42>Options = UnsafeLegacyServerConnect# END LOCAL MODIFICATIONS.include = /etc/crypto-policies/back-ends/opensslcnf.config
While investigating this I used sslyze to analyze the Instant's TLS server configuration and it gave me a couple of findings (I've elided the uninteresting parts):
$ podman run --rm -it docker.io/nablac0d3/sslyze:latest 192.0.2.1:4343[...] SCAN RESULTS FOR 192.168.88.4:4343 - 192.168.88.4 ------------------------------------------------------------------- * Session Renegotiation: Client Renegotiation DoS Attack: OK - Not vulnerable Secure Renegotiation: VULNERABLE - Secure renegotiation not supported [...]COMPLIANCE AGAINST MOZILLA TLS CONFIGURATION -------------------------------------------- Checking results against Mozilla's "intermediate" configuration. See https://ssl-config.mozilla.org/ for more details. 192.168.89.4:4343: FAILED - Not compliant. * ciphers: Cipher suites {'TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256', 'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384'} are supported, but should be rejected. * tls_vulnerability_renegotiation: Server is vulnerable to the insecure renegotiation attack.
Aside from sslyze picking up on the same insecure renegotiation vulnerability that causes OpenSSL to reject connections to the controller, it also notes that a couple of older CBC-mode ciphersuites are still in use. Hopefully the TLS configuration can be modernized in future releases (if not already done in 8.11 or 10).