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 python/cpython#27776 (comment):

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

According to psf/requests#2118 (comment):

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 #30 (comment) 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 #30 (comment) help in your case? ```sh 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. 🤦‍♂️

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. ☹️

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. 😭 😭 🤕

(^ @dwmw2 may be interested in this)