[DRIVERS-2823] Ensure openssl legacy unsafe renegotiation can be configured via the MongoClient Created: 02/Feb/24  Updated: 08/Feb/24

Status: Investigating
Project: Drivers
Component/s: Security, URI Options
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Alex Bevilacqua Assignee: Shane Harvey
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
is related to SERVER-83695 Customer facing SSL certificate error... Closed
is related to NODE-5887 Allow secureOptions to be pass to the... Closed
Driver Changes: Needed
Case:

 Description   

Drivers that use TLS libraries or runtime TLS APIs based on openssl 3 may throw errors such as MongoServerSelectionError: C8320000:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:c:\ws\deps\openssl\openssl\ssl\statem\extensions.c:922: in certain environments (such as when run behind corporate firewalls).

To ensure developers can work around this, the SSL_OP_LEGACY_SERVER_CONNECT SSL option flag should be configurable via the MongoClient.



 Comments   
Comment by Bernie Hackett [ 08/Feb/24 ]

Good point about OpenSSL config. Not all languages use OpenSSL. Java and Rust do not, for example.

Comment by Shane Harvey [ 08/Feb/24 ]

I forgot to add one consideration. Users of any language can already set SSL_OP_LEGACY_SERVER_CONNECT using the OPENSSL_CONF file:

$ cat openssl.cnf
openssl_conf = openssl_init
 
[openssl_init]
ssl_conf = ssl_sect
 
[ssl_sect]
system_default = system_default_sect
 
[system_default_sect]
Options = UnsafeLegacyServerConnect
 
$ OPENSSL_CONF=openssl.cnf python ...

So we could also just document this workaround instead of adding a new driver option for a legacy and insecure SSL feature.

Comment by Shane Harvey [ 07/Feb/24 ]

I've looked into this issue and identified that these types of errors occur due to outdated or buggy SSL proxies. Such proxies mistakenly enforce legacy TLS renegotiation. A real example can be found in openssl/issues/21296:

 What is the SSL inspection product you are using? (Vendor and product version.) The config file flip may be usable as a temporary workaround, but the renegotiation bug is over 13 years old. It's well past time the vendor be informed and implement the fix.

I definitely agree with your take on the fix & 13 year warning haha but I've seen companies like Verizon fail to renew certs. My point being that we can't always rely on the Vendor :sweat_smile:
Vendor: Palo Alto
Model: PA-3250
Version: 10.1.10-h1

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

I have tested MongoDB free tier and M30 found no issues connecting from python with openssl 3 from my home and office networks. So, I believe the least we can do is document this issue so that customers who encounter it will know to upgrade their network proxies or temporarily downgrade their client openssl version to <3.

We can also introduce a new feature to configure SSL_OP_LEGACY_SERVER_CONNECT as this ticket proposes. Given that 1) the choice in network proxy can be outside the control of the app developer and 2) downgrading openssl is not a long term solution, I vote we move forward on introducing a new option.

Note that it's technically possible to set this option by default by I would advise against it due to the security concerns explained in the docs for SECURE RENEGOTIATION:

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

Generated at Thu Feb 08 08:26:29 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.