Ubuntu 22.04 SSL isssue

[suoko]

If you have problems check this:

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

at https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1963834

[dlenski]

Thanks @suoko. Does OPENSSL_CONF=/dev/null do-my-command accomplish the same thing?

[DimitriPapadopoulos]

Also, I suppose the following might help as per https://github.com/python/cpython/pull/27776#issuecomment-1080504060:

ctx = ssl.create_default_context(ssl.Purpose.CLIENT_AUTH)
ctx.options |= 0x4

According to https://github.com/psf/requests/issues/2118#issuecomment-272377938:

You can pass SSLContext objects using TransportAdapters as of v2.12.0.

[dlenski]

This is the same root cause as #37.

[dlenski]

@DimitriPapadopoulos, that looks great.

Does anyone have a publicly-known server that does insecure renegotiation that I can test again? (Doesn't need to be a GP VPN, almost any TLS server that does insecure renegotiation and HTTPS queries should be okay.)

@suoko, @doiiue, @larowlan… maybe you can test this patch as suggested by Dimitri? → https://github.com/dlenski/gp-saml-gui/commits/insecure_renego

[Lalufu]

Running the code from that branch does not fix the issue for me (on Fedora 36). Neither does the ~/ssl.conf trick, so there might be something else going on.

[DimitriPapadopoulos]

@Lalufu This ticket was initially about Ubuntu 22.04. There may be other reasons for the failure on Fedora 36 – either different or additional reasons. Without a log or at least a few error messages, it's hard to tell. if the ~/ssl.conf trick doesn't work for you, chances are it's a different issue. And if so, I wonder whether it would make sense to open a different ticket.

[DimitriPapadopoulos]

@Lalufu Does https://github.com/dlenski/gp-saml-gui/issues/30#issuecomment-898660223 help in your case?

sudo update-crypto-policies --set LEGACY

[Lalufu]

On Mon, May 16, 2022 at 05:36:33AM -0700, Dimitri Papadopoulos Orfanos wrote:

@Lalafu This ticket was initially about Ubuntu 22.04. There may be other reasons for the failure on Fedora 36 – either different or additional reasons. Without a log or at least a few error messages, it's hard to tell. if the ~/ssl.conf trick doesn't work for you, chances are it's a different issue. And if so, I wonder whether it would make sense to open a different ticket.

I'm pretty sure it's the same issue, as it presents the same error message for the same reason (Fedora 36 now ships OpenSSL 3.0). The config change needs to be made at a slightly different place, but using Options = UnsafeLegacyRenegotiation does fix it once you've found the right file to put it in.

[DimitriPapadopoulos]

The config change needs to be made at a slightly different place, but using Options = UnsafeLegacyRenegotiation does fix it once you've found the right file to put it in.

So the ~/ssl.conf trick does work for you, doesn't it? If so, what's the exact difference between Ubuntu 22.04 and Fedora 36? If not, what's the "right file"?

[Lalufu]

On Mon, May 16, 2022 at 05:40:41AM -0700, Dimitri Papadopoulos Orfanos wrote:

@Lalufu Does https://github.com/dlenski/gp-saml-gui/issues/30#issuecomment-898660223 help in your case?

sudo update-crypto-policies --set LEGACY

It does not.

What I did (and what solved the issue) was following https://ask.fedoraproject.org/t/cannot-connect-to-wpa2-enterprise-university-wifi-eduroam-on-fedora-36/20288/5 which advises to put

Options = UnsafeLegacyRenegotiation

into the [crypto_policy] section of /etc/pki/tls/openssl.cnf. So basically the same thing as the ssl.conf above, just in a different place (openssl config files being the nightmare that they are)

[Lalufu]

On Mon, May 16, 2022 at 05:45:58AM -0700, Dimitri Papadopoulos Orfanos wrote:

The config change needs to be made at a slightly different place, but using Options = UnsafeLegacyRenegotiation does fix it once you've found the right file to put it in.

So the ~/ssl.conf trick does work for you, doesn't it? If so, what's the exact difference between Ubuntu 22.04 and Fedora 36? If not, what's the "right file"?

It does not work as presented above. Preparing a ~/ssl.conf and calling the program with the OPENSSL_CONF env var pointing towards it does not solve the issue on F36 (at least for me).

Putting Options = UnsafeLegacyRenegotiation into the [crypto_policy] section of /etc/pki/tls/openssl.cnf does.

Ultimately those two do the same thing, re-enabling unsafe renegotiaton, per-process on Ubuntu and system wide on Fedora. I'm sure there is a way to the per-process thing on Fedora as well, but I don't know how.

[dlenski]

Thanks for testing that patch @Lalufu. Hrm.

This is extremely frustrating, because we know there's a (relatively trivial) shared cause of the issues here: OpenSSL is refusing to connect to servers that use "unsafe legacy renegotiation."

What we need is a consistent and reliable mechanism to (re)enable that unsafe legacy renegotiation in the library.

That's going to be very hard to test for without a server that exhibits it. If anyone has one that they can share here (or even email me in private) that'd be helpful…

Does anyone have a publicly-known server that does insecure renegotiation that I can test again? (Doesn't need to be a GP VPN, almost any TLS server that does insecure renegotiation and HTTPS queries should be okay.)

[Legimet]

I've been using gp-saml-gui for a couple of years, and I have always had the same issue. Instead of dealing with config files, I just add the following line at the beginning of gp_saml_gui.py and test-globalprotect-login.py: requests.packages.urllib3.util.ssl_.DEFAULT_CIPHERS += ':!DH'

Actually, I didn't read the whole thing. My issue is a different one, I get the following error if I don't include that line: gp_saml_gui.py: error: SSL error: [SSL: DH_KEY_TOO_SMALL] dh key too small (_ssl.c:997)

[dlenski]

@legimet, interesting. Looks like you've run into (yet another) way in which VPN servers can have old/bad/insecure crypto. :man_facepalming:

As I wrote in https://github.com/dlenski/gp-saml-gui/issues/37#issuecomment-1063514658…

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:

Actually, that was too optimistic. Between Python requests, GTK WebView, and then calling openconnect, connecting with gp-saml-gui involves connecting to the same TLS server with up to three different TLS libraries.

In openconnect, we've already put in a ton of work to forcibly enable using old/bad crypto so that users can continue to connect to old/bad servers. :sob: :sob: :face_with_head_bandage:

(^ @dwmw2 may be interested in this)

[DimitriPapadopoulos]

Perhaps the workarounds could be documented in the README or a wiki page, in this project or the OpenConnect documentation:

• openconnect: OpenConnect is usually linked with GnuTLS nowadays, but alternatively it might be linked with OpenSSL. I am not certain the OPENSSL_CONF=~/ssl.conf openconnect workaround documented in https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1963834/comments/6 works with GnuTLS as well as OpenSSL.
• Python requests: Python uses OpenSSL, I expect both the python/cpython#/27776 (comment) and the OPENSSL_CONF=~/ssl.conf workarounds to work.
• I am not sure what the GTK WebKit in Python uses under the hood. The OPENSSL_CONF=~/ssl.conf might do the trick though, or not.

I thought the OPENSSL_CONF=~/ssl.conf workaround would solve all issues. Unfortunately, it looks like in doesn't always help: on Fedora 36 modifying the system configuration file /etc/pki/tls/openssl.cnf is required.

An alternative to modifying the system configuration file /etc/pki/tls/openssl.cnfmight be to programmatically enable SSL_OP_LEGACY_SERVER_CONNECT or SSL_OP_NO_RENEGOTIATION - see paragraph SECURE RENEGOTIATION of the SSL_CTX_set_options man page.

@legimet Can you confirm that both the OPENSSL_CONF=~/ssl.conf trick and the requests.packages.urllib3.util.ssl_.DEFAULT_CIPHERS trick from https://github.com/dlenski/gp-saml-gui/issues/42#issuecomment-1133049047 documented in Python - requests.exceptions.SSLError - dh key too small work?

So far, it appears the following might work to connect to insecure legacy VPN gateways:

1. Start with the requests.packages.urllib3.util.ssl_.DEFAULT_CIPHERS trick documented in https://github.com/dlenski/gp-saml-gui/issues/42#issuecomment-1133049047, it is a straightforward change that might help overcome some OpenSSL issues.
2. Then attempt to re-enable legacy renegotiation, ideally we should do that programmatically with SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION or perhaps SSL_OP_NO_RENEGOTIATION instead of modifying the system configuration file /etc/pki/tls/openssl.cnf.
3. If all the above fail, user the OPENSSL_CONF=~/ssl.conf trick.
4. If all the above fail, users might haveno other option than modifying system files such as /etc/pki/tls/openssl.cnf.

I would suggest adding an --allow-insecure-crypto option to gp_saml_gui.py that could try above workarounds, either sequentially or together. @dlenski Would you agree adding that option and starting experimenting with possible workarounds?

In any case, it might be worth trying to catch errors caused by legacy insecure servers and print an error message with suggestions.

[DimitriPapadopoulos]

I'm on Ubuntu 22.04. Which exact issue can I reproduce with vpp.itunes.apple.com and how?

[DimitriPapadopoulos]

There are different kinds of insecure negotiations. Does this VPN server reproduce the initial issue reported on Ubuntu 22.04? Any way, we will give it a try.

[DimitriPapadopoulos]

Good new, https://github.com/dlenski/what-vpn/pull/19 appears to be working around the SSL errors of what-vpn on my Ubuntu 22.04 machine.

Before the patch:

$ what-vpn -v vpp.itunes.apple.com

Sniffing vpp.itunes.apple.com ...
  Is it AnyConnect/OpenConnect? SSL error
  => SSL errors (tried 1/12 sniffers)
$ 

After the patch:

$ what-vpn -v vpp.itunes.apple.com

Sniffing vpp.itunes.apple.com ...
  Is it AnyConnect/OpenConnect? connection error
  Is it Juniper/Pulse? no match
  Is it PAN GlobalProtect? no match
  Is it Barracuda? no match
  Is it Check Point? connection error
  Is it SSTP? no match
  Is it OpenVPN? no match
  Is it Fortinet? no match
  Is it Array Networks? no match
  Is it F5 BigIP? no match
  Is it SonicWall NX (formerly Dell)? no match
  Is it Aruba VIA? no match
  => no match
$ 

By the way, what-vpn does not identify vpp.itunes.apple.com as a GlobalProtect VPN. But is vpp.itunes.apple.com a working GlobalProtect VPN? As far as I can see, it is hardly responding. Any way, it helps reproduce the SSL error:

$ ./gp_saml_gui.py vpp.itunes.apple.com
Looking for SAML auth tags in response to https://vpp.itunes.apple.com/global-protect/prelogin.esp...
usage: gp_saml_gui.py [-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.py: error: SSL error: [SSL: UNSAFE_LEGACY_RENEGOTIATION_DISABLED] unsafe legacy renegotiation disabled (_ssl.c:997)
$ 

And it also helps confirm that the new option --allow-insecure-crypto introduced by #48 works around the above error:

$ ./gp_saml_gui.py --allow-insecure-crypto vpp.itunes.apple.com
Looking for SAML auth tags in response to https://vpp.itunes.apple.com/global-protect/prelogin.esp...
usage: gp_saml_gui.py [-h] [--no-verify] [-C COOKIES | -K] [-g | -p] [-c CERT] [--key KEY] [-v | -q] [-x | -P | -S] [-u]
                      [--clientos {Linux,Mac,Windows}] [-f EXTRA] [--allow-insecure-crypto]
                      server [openconnect_extra ...]
gp_saml_gui.py: error: This does not appear to be a GlobalProtect prelogin response
Check in browser: https://vpp.itunes.apple.com/global-protect/prelogin.esp?tmp=tmp&kerberos-support=yes&ipv6-support=yes&clientVer=4100&clientos=Linux
$ 

Thank you for providing vpp.itunes.apple.com as an example of legacy server.

[DimitriPapadopoulos]

@suoko Does it work better for you on Ubuntu 22.04 with option --allow-insecure-crypto introduced in #48? Please give this branch a try: https://github.com/DimitriPapadopoulos/gp-saml-gui/tree/insecure_crypto

@legimet I believe #48 will work around not only the unsafe legacy renegotiation case reported by @suoko, but also the weak Diffie-Hellman key exchange size case reported by you. Can you give it a try?

@Lalufu If #48 doesn't work for you on Fedora 36, please open a new issue.

[Lalufu]

On Sat, Jun 11, 2022 at 11:10:51AM -0700, Dimitri Papadopoulos Orfanos wrote:

@suoko Does it work better for you on Ubuntu 22.04 with option --allow-insecure-crypto introduced in #48? Please give this branch a try: https://github.com/DimitriPapadopoulos/gp-saml-gui/tree/insecure_crypto

That URL 404's for me

-- "If the idea of a protocol behaving like a rabid, diseased, sex-crazed bunny rabbit appeals to you, AppleTalk is for you." -- John Kennedy, in comp.dcom.sys.cisco

[DimitriPapadopoulos]

@Lalufu Yes, that branch has been merged. Just test the latest version from the master branch.

[Lalufu]

On Sun, Jun 12, 2022 at 01:18:45PM -0700, Dimitri Papadopoulos Orfanos wrote:

@Lalufu Yes, that branch has been merged. Just test the latest version from the master branch.

I can confirm that the master branch with --allow-insecure-crypto works on F36 without having to change global SSL parameters.