option --allow-insecure-crypto results in [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain

[bugfood]

Hello,

background

I should first give some background on this issue, since it may help somebody else in the same situation.

I have run into a recent problem where I get an error:

gp_saml_gui.py: error: SSL error (try --allow-insecure-crypto to ignore): [SSL: UNSAFE_LEGACY_RENEGOTIATION_DISABLED] unsafe legacy renegotiation disabled (_ssl.c:1029)

I think that this is distinct from other reports of that particular error, since it only happens with recent versions of openssl: version 3.4.0 or 3.4.1 (latest at this time). Specifically, anything that has this commit:
openssl/openssl@972ee92

I read enough to be pretty sure I understand, but I am not an expert on TLS details. My understanding follows.

There are two mechanisms for specifying secure renegotiation:

• a renegotiation_info extension
• a TLS_EMPTY_RENEGOTIATION_INFO_SCSV "cipher suite"

Clients MUST include either; including both is NOT RECOMMENDED.
https://datatracker.ietf.org/doc/html/rfc5746#section-3.4

Servers MUST support both mechanisms:
https://datatracker.ietf.org/doc/html/rfc5746#section-3.6

With that for context, the PR description makes sense:
openssl/openssl#24161

In brief, openssl used to use TLS_EMPTY_RENEGOTIATION_INFO_SCSV, but now uses renegotiation_info.

The Palo Alto seems to only be supporting TLS_EMPTY_RENEGOTIATION_INFO_SCSV. My understanding of this is that by only supporting one mechanism, the Palo Alto is non-compliant with RFC5746 section 3.6.

OpenSSL is compliant with RFC5746 either way (before and after the referenced change), but after the change is additionally compliant with RFC7525 section 3.5.
openssl/openssl#18790
https://datatracker.ietf.org/doc/html/rfc7525#section-3.5

I don't know what Palo Alto software version this is from; it's possible that an upgrade would help--especially an upgrade to support TLS 1.3, which does not make use of renegotiation at all.

issue

Meanwhile, I tried the suggested option --allow-insecure-crypto. This resulted in an error:

 $ ./gp_saml_gui.py --allow-insecure-crypto --ignore-redirects --gateway vpn.example.com

(gp_saml_gui.py:2423531): dbind-WARNING **: 17:29:25.855: AT-SPI: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files
Looking for SAML auth tags in response to https://vpn.example.com/ssl-vpn/prelogin.esp...
usage: gp_saml_gui.py [-h] [--no-verify] [-C COOKIES | -K] [-i] [-g | -p] [-c CERT] [--key KEY] [-v | -q] [-x | -P | -S | -E] [-u]
                      [--clientos {Mac,Windows,Linux}] [-f EXTRA] [--allow-insecure-crypto] [--user-agent USER_AGENT] [--no-proxy]
                      server [openconnect_extra ...]
gp_saml_gui.py: error: SSL certificate error (try --no-verify to ignore): [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain (_ssl.c:1029)

The VPN gateway in question does have a cert signed by a recognized CA, though; it's not self-signed. If I use a version of openssl prior to the commit mentioned above, then:

• without --allow-insecure-crypto, gp-saml-gui works fine
• with --allow-insecure-crypto, gp-saml-gui gets the same CERTIFICATE_VERIFY_FAILED error

I looked at the code for this in gp_saml_gui.py. I can see that it is creating its own SSLContext:
https://github.com/dlenski/gp-saml-gui/blob/21cce40/gp_saml_gui.py#L241

I suspect that when SSLContext is created automatically (in requests or urllib3?), then a parameter is set somehow to make certificate validation work properly. I was unable to narrow this down, though.

outlook

If there's a possible fix for this, that would be nice; otherwise, this report may at least help others who hit the same renegotation issue.

Long term, the best resolution is probably to get this fixed server-side.

Short term, a workaround for the renegotiation issue is to use a custom openssl config file, as described here:
#37 (comment)

Thanks,
Corey

[bugfood]

As a follow up to this, supporting TLS 1.3 on the Palo Alto side does indeed make the problem go away.

-Corey