Please Show ServerKeyExchange signed_params Hash Function

[jrchamp]

The ServerKeyExchange message for Forward Secret, non-anonymous ciphers contains a signed_params hash: https://tools.ietf.org/html/rfc5246#section-7.4.3

The options are a combination of algorithm {RSA, DSA, ECDSA} and digest {SHA1, SHA256, SHA384, SHA512}. Note: the hash and signature algorithms MUST be compatible with the key in the server's end-entity certificate (e.g. ECDSA certificate, must have an ECDSA+SHA* signature).

Why is this relevant? Chrome 56 recently dropped support for ECDSA+SHA1 and ECDSA+SHA512. Plus, it's helpful to know that your system is configured to return SHA1-strength hashes; maybe then we'll be able to improve the situation before Chrome drops support for a production website.

Thank you for your consideration.

[alex]

Showing the data is a great start, I think it would also make sense to have the UI highlight it, or have it be integrated in the ratings.

My understanding is that while there are a lot of servers still using SHA1 in SKX, they are not running the latest version of whatever software they use for TLS termination, so simply upgrading to the latest will fix this.

SSLLabs is an incredible tool for having more forward deployments, having it highlight this could be a good way to get more people to upgrade.

[jrchamp]

Forgot to include this in my original message: One of my development websites stopped working in Chrome 56 as a result of this, even though it was getting an A+, because SHA1 was being negotiated every time.

[jrchamp]

Some older server software was even offering RSA+MD5, which received the attack codename SLOTH. Summary: Signatures are weaker than previously thought, rendering MD5 largely useless and reducing SHA1 strength to 77 bits instead of the 160 bits of preimage strength one would typically expect for an authenticated encryption impersonation attack.

[alex]

FWIW, if anyone is looking for affected websites, https://censys.io/domain?q=443.https.tls.signature.hash_algorithm%3Asha1 is an easy way to find some.

[sigmavirus24]

For others reading this, GitHub's HTML rendering doesn't consider the closing " to be a valid part of @alex's URL. This link is the same and should work (so future readers don't have to update the search.

https://censys.io/domain?q=443.https.tls.signature.hash_algorithm%3A%22sha1%22 may also work better with the "'s percent-encoded.

[davidben]

One thing of note: any server using SChannel on older Windows will preferentially sign SHA-1 if offered but are capable of signing SHA-2 if SHA-1 isn't offered. So those are annoying for measuring, but not a blocker for getting SHA-1 out of here.

[Darkspirit]

Germany's first public TV channel https://www.daserste.de uses RSA_PKCS1_SHA1, therefore I can't connect with Debian's default OpenSSL config or with Rustls. It would be good if SSLLabs could warn about this. Chrome warns, too. See briansmith/webpki#110.

[Darkspirit]

@naumanshah03
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/yaJcs4p9LNI
Please warn about the highly-problematic RSA_PKCS1_SHA1 handshake signature:
https://dev.ssllabs.com/ssltest/analyze.html?d=daserste.de

[Darkspirit]

• https://gitlab.com/gnutls/gnutls/-/issues/910 "Mark SHA1 as insecure for any use"
• Reduce the security bits for MD5 and SHA1 based signatures in TLS openssl/openssl#10787 "Reduce the security bits for MD5 and SHA1 based signatures in TLS"

[mnalis]

I've also been hit with this in #740 ; ssllabs.com shows A+ score with no indications of any problems or compatibility issues, but LWP, curl and openssl client fail on Debian Buster fail to connect with:

error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type

Perhaps a openssl s_client -connect (or a popular curl, which uses the same libs) can be added as a client to test connecting with, to represent automated API accesses? And lowering the score to at least B with a note why might be useful to indicate problems with such sites.

Because it is near to impossible to explain that the problem exists at the server side, when reputable source as ssllabs.com claims that everything is A+ - and only alternative is forcefully dropping security on client side (where such settings will continue to linger likely forever - as we all know, there is nothing more permanent than a temporary solution that works) is very bad slippery slope to purposefully enter.

[gbl]

I (server owner) ran into the same problem - a customer said they just weren't able to connect (to an old server of mine which supports TLS 1.2 but not 1.3) , while no browser had any problem, and ssllabs said A+ for my site. At least they sent me a curl command to prove it, and after running curl, openssl s_client and wiresharking I found the server uses SHA1 in the signature hash algorithm, which means newer curls and openssls won't connect in default mode.

It would be great if the scanner could at least emit a warning in this case.

By the way, that was an Ubuntu 14.04 (old, I know ...) with the last available apache (2.4.7) and openssl (1.0.1f) if that info is helpful for reproducing the problem.

Guess I'll finally replace the server with a new one, so at least one good thing came out of this, but a message in the ssl scanner would have saved me a few hours.