openssl 3.0 - SSL: UNSAFE_LEGACY_RENEGOTIATION_DISABLED]

It looks like this was added in:

https://github.com/openssl/openssl/commit/72d2670bd21becfa6a64bb03fa55ad82d6d0c0f3

in order to address servers that have not yet been updated for CVE-2009-3555.

It's possible to add a flag at the C level to connect insecurely, SSL_OP_LEGACY_SERVER_CONNECT, but I don't see this added to python:

https://bugs.python.org/issue44888
https://github.com/python/cpython/pull/27776

Thus it might not be easily reachable from Python programs.

Best would be to update the remote server to address CVE-2009-3555 (it might also be known as "support RFC 5746"). I'm not sure what to suggest for programs written in Python.

Thanks

To be clear, the root issue is that the server is using an outdated, insecure protocol that has been deemed so for more than a decade, and OpenSSL finally decided to disable it by default. The "proper" way to fix this would be for them to upgrade.

Now, that being said, we live in the real world and our users probably don't have the power to make this decision.

I really don't understand why the upstream Python PR has been closed, it'd have made our lives easier. We *could* carry the patch in our Python 3.10 package, but that's just moving the problem, as our more technical users would have this escape hatch but the others would still be left out.

I'll get in touch with OpenSSL upstream to see if it's conceivable to expose this flag as a configuration option.

... And while looking for what exactly to suggest upstream, I realized that GitHub search only prints out the first match in a given file, which mean I missed the config options part of https://www.openssl.org/docs/man3.0/man3/SSL_CONF_cmd_value_type.html (search for UnsafeLegacyServerConnect), which, combined with https://www.openssl.org/docs/man3.0/man5/config.html makes me think the following snippet should work, assuming the Python modules actually loads the config file:

[ssl_configuration]
 client = client_tls_config

 [client_tls_config]
 Options = UnsafeLegacyServerConnect

This is completely untested though :)

FWIW I'm seeing this with the openconnect-sso (https://github.com/vlaci/openconnect-sso) package on jammy. I just tried adding the following to my /etc/ssl/openssl.cfg:

[ssl_configuration]
client = client_tls_config

[client_tls_config]
Options = UnsafeLegacyServerConnect

With no luck :(

I tried also adding the following:

[openssl_init]
providers = provider_sect
ssl_conf = ssl_configuration

as I wasn't sure whether the [ssl_configuration] section would otherwise get used for anything, but that didn't seem to make a difference.

The end of the file is

[ssl_configuration]
client = client_tls_config

# https://www.mail-archive.com/openssl-users%40openssl.org/msg90598.htm
l
# https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1963834
[client_tls_config]
Options = UnsafeLegacyRenegotiation

Ok, I did get my case to work by creating ~/ssl.conf containing:

openssl_conf = openssl_init

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
Options = UnsafeLegacyRenegotiation

And then did OPENSSL_CONF=~/ssl.conf do-my-command

that works. I don't know why the system-wide file does not.

We are having the same issue.
Out setup:
Ubuntu 22.04 (daily) + GlobalProtect Version 6 from Palo Alto Networks + SAML Auth
We found a system-wide workaround.
Modify the existing openssl config file, path: /usr/lib/ssl/openssl.cnf
with your already mentioned settings (just add the missings ones):
====>8======================================
openssl_conf = openssl_init

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
Options = UnsafeLegacyRenegotiation
====8<======================================

For the moment it is working fine for us.

I'm marking this bug as `Won't Fix` as this new behavior is a deliberate upstream choice that is documented in their migration documentation https://www.openssl.org/docs/manmaster/man7/migration_guide.html

Granted, the documentation in question isn't exactly obvious (search for RFC 5746), but we've showed here that there's a workaround for those who can't convince their server admins to upgrade to a more secure SSL implementation. Thank you all for your work on testing and documenting said workarounds!

It's a bit of an 'own goal' if this gets marked as 'won't fix'. As students upgrade to 22.04 where I work they will find they can't connect to the institutions or research centre wireless network. They won't care that the SSL change is protecting them from an old SSL bug, they will just come back 'it works in windows but not Ubuntu'.
Central IT services who run the wireless will just shrug and say 'Linux not supported'.
Need to make it easier to find how to turn on the Legacy insecure mode.

Yes, managing the configurations for the huge variety of cryptography toolkits on a Linux system is definitely something of a chore. It would be nice to give people one command they could use to return to unsafe-but-compatible cryptography -- or enforce only modern cryptography.

Our friends at Red Hat have prepared https://gitlab.com/redhat-crypto/fedora-crypto-policies -- while a version of this is packaged: https://launchpad.net/ubuntu/+source/crypto-policies -- I don't believe it actually works on Ubuntu: https://bugs.launchpad.net/ubuntu/+source/crypto-policies/+bug/1926664

Maybe someday.

Thanks

FYI, to restart wpa-supplicant after these edits:

systemctl restart wpa_supplicant

Can someone please tell the process of the workaround as i upgraded to ubuntu 22.04 and can't connect to my university wifi and i can't understand the details you guys are talking about

I am from this bug post: https://www.reddit.com/r/Ubuntu/comments/uf68rn/major_issues_connecting_ubuntu_2204_lts_to/

I am wondering if this but report is related to it. I got the following error message when using the python version of SecureW2 client:

(Pdb) key_valid(self.file, passphrase=passphrase)
*** sslengine.SSLEngineError: Failed to invoke /bin/openssl with arguments ['pkcs12', '-in', '/home/leo/.joinnow/tls-client-certs/sw2-joinnow-client-cert-da39a3ee5e6b4b0d3255bfef95601890afd80709_20210721-101520_3815.p12', '-nocerts', '-nomacver', '-out', '/home/leo/.joinnow/tls-client-certs/sw2-joinnow-client-cert-da39a3ee5e6b4b0d3255bfef95601890afd80709_20210721-101520_3815.key', '-passin', 'file:/proc/12303/fd/5', '-aes256', '-passout', 'file:/proc/12303/fd/6']: Command '['/bin/openssl', 'pkcs12', '-in', '/home/leo/.joinnow/tls-client-certs/sw2-joinnow-client-cert-da39a3ee5e6b4b0d3255bfef95601890afd80709_20210721-101520_3815.p12', '-nocerts', '-nomacver', '-out', '/home/leo/.joinnow/tls-client-certs/sw2-joinnow-client-cert-da39a3ee5e6b4b0d3255bfef95601890afd80709_20210721-101520_3815.key', '-passin', 'file:/proc/12303/fd/5', '-aes256', '-passout', 'file:/proc/12303/fd/6']' returned non-zero exit status 1.

where the `key_valid` is from module `sslengine`.

How can I fix this issue?

You'll need to contact your provider. I'm guessing their script isn't compatible with OpenSSL 3.0, but without more information (such as the stdout/stderr of the openssl CLI invocation here) there isn't much we can do on this end.

Whatever the precise issue though, it's almost certainly NOT related to the OP bug :).