Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Ubuntu 22.04 SSL isssue #42

Open
suoko opened this issue Apr 21, 2022 · 22 comments
Open

Ubuntu 22.04 SSL isssue #42

suoko opened this issue Apr 21, 2022 · 22 comments
Labels
duplicate This issue or pull request already exists

Comments

@suoko
Copy link

suoko commented Apr 21, 2022

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
Copy link
Owner

dlenski commented Apr 22, 2022

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

@DimitriPapadopoulos
Copy link
Contributor

DimitriPapadopoulos commented May 5, 2022 •
edited
Loading

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
Copy link
Owner

dlenski commented May 12, 2022

This is the same root cause as #37.

@dlenski dlenski added the duplicate This issue or pull request already exists label May 12, 2022
@dlenski
Copy link
Owner

dlenski commented May 12, 2022 •
edited
Loading

@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
Copy link

Lalufu commented May 16, 2022

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
Copy link
Contributor

DimitriPapadopoulos commented May 16, 2022 •
edited
Loading

@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
Copy link
Contributor

@Lalufu Does #30 (comment) help in your case?

sudo update-crypto-policies --set LEGACY

@Lalufu
Copy link

Lalufu commented May 16, 2022 via email

@DimitriPapadopoulos
Copy link
Contributor

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
Copy link

Lalufu commented May 16, 2022 via email

@Lalufu
Copy link

Lalufu commented May 16, 2022 via email

@dlenski
Copy link
Owner

dlenski commented May 16, 2022 •
edited
Loading

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
Copy link

Legimet commented May 20, 2022 •
edited
Loading

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
Copy link
Owner

dlenski commented May 21, 2022 •
edited
Loading

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

@DimitriPapadopoulos
Copy link
Contributor

DimitriPapadopoulos commented May 21, 2022 •
edited
Loading

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 #42 (comment) 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 Ubuntu 22.04 SSL isssue #42 (comment), 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.

@dlenski dlenski mentioned this issue May 22, 2022
Merged
@DimitriPapadopoulos
Copy link
Contributor

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

@DimitriPapadopoulos
Copy link
Contributor

DimitriPapadopoulos commented Jun 6, 2022 •
edited
Loading

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
Copy link
Contributor

DimitriPapadopoulos commented Jun 11, 2022 •
edited
Loading

Good new, dlenski/what-vpn#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
Copy link
Contributor

DimitriPapadopoulos commented Jun 11, 2022 •
edited
Loading

@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
Copy link

Lalufu commented Jun 12, 2022 via email

@DimitriPapadopoulos
Copy link
Contributor

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

@Lalufu
Copy link

Lalufu commented Jun 13, 2022 via email

@trung10000 trung10000 mentioned this issue Aug 21, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
duplicate This issue or pull request already exists
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@dlenski @DimitriPapadopoulos @suoko @Lalufu @Legimet