Warn when SHA-1 is used anyhow

[dilyanpalauzov]

Firefox 89/Fedora 34 cannot connect to www.euroclear.com . ./testssl.sh www.euroclear.com says it should work.

According to https://www.reddit.com/r/firefox/comments/jfhb9d/my_internet_bank_just_broke_in_firefox_tls/ , https://github.com/ssllabs/ssllabs-scan/issues/740, and https://tools.ietf.org/html/rfc5246#section-7.4.3 “If the client has offered the "signature_algorithms" extension, the signature algorithm and hash algorithm MUST be a pair listed in that extension.”

testssl.sh shall report some problem for www.euroclear.com, since Firefox on Fedora says “SSL_ERROR_UNSUPPORTED_HASH_ALGORITHM”.

[teward]

It sounds like this might be relevant: https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2

... and that this is not going to be a bug in TestSSL which uses its own OpenSSL and OpenSSL directly.

From that page:

Fedora includes several cryptographic components who's security doesn't remain constant over time. Algorithms such as (cryptographic) hashing and encryption typically have a lifetime after which they are considered either too risky to use or plain insecure. That would mean we need to phase out such algorithms from the default settings, or completely disable if they could cause irreparable issue.

While in the past we did not disable algorithms in a consistent way (different applications utilized different policies), today we have a system-wide policy followed by a large part of Fedora components. That allows us to move consistently and deprecate algorithms system-wide. For rationale see RFC 7457 for a more complete list of attacks taking advantage of legacy crypto algorithms.

The changes for default policy are:

• Keep only TLS 1.2 (and TLS 1.3 when available) as enabled protocols and move the TLS 1.x, x<=1 to legacy level.
• Require finite field parameters (RSA, Diffie-Hellman) of 2048 and more in the default settings
• Disable SHA1 support for use in signatures (X.509 certificates, TLS, IPSEC handshakes)

In Ubuntu 20.04 which does not have all these enforcements in place, for example, my system, Firefox 89 can reach the site. However it's cert sigs in all intermediate certs for the site you're referring to has only SHA1 sigs, which is insufficient in current standards.

You will need to try updating your policy first in Fedora.

You may want to do either:

update-crypto-policies --set DEFAULT:FEDORA32

... or

update-crypto-policies --set LEGACY which is even more insecure.

This is directly from the fedora project wiki. You may need to default to Fedora32 default compatibility if you MUST access that page.

---

If one of these command changes is done, and the site works, then you can only blame Fedora's changes to defaults. Fedora Firefox doesn't run the bundled OpenSSL executables that TestSSL does so the configuration changes done by Fedora to the libssl and such on Fedora won't match what's in the TestSSL OpenSSL (which is intentional, so TestSSL can actually analyze if older protos, etc. are supported)

[dilyanpalauzov]

My reading is, that Fedora has disabled SHA-1 support for use in signatures (X.509 certificates, TLS, IPSEC handshakes), and that site uses SHA-1.

Since SHA-1 is anyway considered insecure, testssl.sh shall warn, when SHA1 is used.

[teward]

So, in reality, this is what I found.

This is the certificate on the actual site and it's hash data (from Google Chrome's cert digging):

This shows the site's certificate is a SHA256 signed certificate which is fine.

However, the intermediate and root certificates are the ones that have SHA1 sigs:

Intermediate certificates with SHA1 are still technically 'invalid hashes' but for various reasons they aren't updated regularly.

Most root CA certificates' signature hash is irrelevant because they're self signed. THe intermediate certificates are a little less of a priority as the site level certificate, but the industry generally has accepted SHA1 intermediate certs as 'okay' until they expire, those usually aren't reissued by CAs either until expiry unless htere's a key compromise because then Google, Microsoft, FIrefox, etc. have to update the entire certificate stores that default-ship with a system.

From the purposes of TestSSL it's testing the end certificate, which is a SHA256 signature. The intermediates which are already in the certificate store by industry practice usually don't need to be updated or reissued for SHA256, until they need renewed.

I'm not sure it's "not a bug" that TestSSL isn't verifying the intermediate chain having valid sigs. However, Fedora not accepting intermediate SHA1 certificates looks more like a bug in Fedora than a bug in TestSSL, as not all intermediate certificates have been updated yet for SHA256 (and in some cases can't be done without a huge set of reissuances of site certificates).

[dilyanpalauzov]

Since the SHA-1 hash on the root certificate shall not be a problem, I filled https://bugzilla.redhat.com/show_bug.cgi?id=1821875#c7 towards Fedora.

[teward]

Since the SHA-1 hash on the root certificate shall not be a problem, I filled https://bugzilla.redhat.com/show_bug.cgi?id=1821875#c7 towards Fedora.

They will likely close it as a duplicate of the bug i provided earlier, point you at https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 and then subsequently suggest to you to use update-crypto-policies --set DEFAULT:FEDORA32 or update-crypto-policies --set LEGACY on your system.

[dilyanpalauzov]

https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2#Current_status points to Tracker bug #1821875.

[dcooper16]

See #1004.