SSL error : "SSL: UNSAFE_LEGACY_RENEGOTIATION_DISABLED"

[doiiue]

Hi @dlenski !

After upgrading from Ubuntu 20.04 to 22.04 I get the following SSL error when connecting to my office VPN :

gp-saml-gui -v --clientos=Windows zehost.domain.com
Looking for SAML auth tags in response to https://zehost.domain.com/global-protect/prelogin.esp...
usage: gp-saml-gui [-h] [--no-verify] [-C COOKIES | -K] [-g | -p] [-c CERT] [--key KEY] [-v | -q] [-x | -P | -S] [-u] [--clientos {Linux,Mac,Windows}] [-f EXTRA] server [openconnect_extra ...]
gp-saml-gui: error: SSL error: [SSL: UNSAFE_LEGACY_RENEGOTIATION_DISABLED] unsafe legacy renegotiation disabled (_ssl.c:997)

(same results using "--clientos=Linux", for unknown reasons, IT is asking us to use "--clientos=Windows")

It's been working fine for almost 2 years under Ubuntu 20.04. Works fine from a VM using Ubuntu 21.10. Fails in a VM with Ubuntu 22.04. Any hints on how I could gather more details about this ? Looking for ways to document the issue further to either bring info here, or on Ubuntu side.

Thanks !

[doiiue]

Ubuntu 22.04 (release date is schedule for April 21, 2022) now use openssl 3.0. My understanding is that legacy renegotiation would be disabled in this version. https://www.openssl.org/docs/man3.0/man3/SSL_get_secure_renegotiation_support.html

So gp-saml-gui is fine along with all the python3 modules used. I compared them between Ubuntu 21.10 and 22.04 and nothing changed.

I have no control of the server side other then inform security team.
I'll update here if I find a workaround.

[doiiue]

Filed a bug with Ubuntu against openssl : https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1963834

[dlenski]

Filed a bug with Ubuntu against openssl : https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1963834

Thank you for filing this! Lots of VPNs use long-obsolete TLS versions/crypto/features, and the push among Linux distributions to forbid this on the client library side is very frustrating, since the end users can't do anything about it. (cf. openconnect MR !114).

gp-saml-gui is unusually susceptible to these issues, since it uses both Python's requests module for the initial automated requests, as well as GTK WebView for the graphical interface, so it has to deal with TLS issues with both. :frowning_face:

[larowlan]

https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1963834/comments/6 Seems to work

[DimitriPapadopoulos]

@doiiue @larowlan The OPENSSL_CONF=~/ssl.conf trick might work, but I'd rather find an alternative to enable insecure renegotiation programmatically from within the script.

Could you try the following branch with option --allow-insecure-crypto? https://github.com/DimitriPapadopoulos/gp-saml-gui/tree/insecure_crypto

[DimitriPapadopoulos]

See also https://github.com/dlenski/what-vpn/issues/6.

When running Python scripts on Ubuntu 22.04, I have to force the following OpenSSL configuration file to be able to connect to all sorts of obsolete VPN servers:

openssl_conf = openssl_init

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
Options = UnsafeLegacyRenegotiation
CipherString = DEFAULT:@SECLEVEL=1

I'm not certain yet how to enforce that programmatically, from within the Python script.

[DimitriPapadopoulos]

@doiiue @larowlan I have updated this branch: https://github.com/DimitriPapadopoulos/gp-saml-gui/tree/insecure_crypto

Could you give it a try with option --allow-insecure-crypto?

[pboushy]

This issue was eventually resolved by Palo Alto as part of a PanOS update.

The issue is logged as PAN-184630, and was resolved in the following versions: 9.1.17, 10.1.11, 10.2.5, and 11.0.2.

[dlenski]

Thank you @pboushy, that's very helpful.

I suspect that many users have now gotten used to adding --allow-insecure-crypto to their gp-saml-gui command-lines now.

It might be a good idea to extract the policy/version (= server software version) out of the portal XML, and warn the user if they're using --allow-insecure-crypto on a version where it shouldn't be necessary… or vice versa. Want to take a crack at it? 😬

[pboushy]

It might be a good idea to extract the policy/version (= server software version) out of the portal XML, and warn the user if they're using --allow-insecure-crypto on a version where it shouldn't be necessary… or vice versa. Want to take a crack at it?

Yeah, I'll submit a PR in a few days with the fix.

Should we reopen this issue since we have a plan to change how this issue is handled?