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.

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

Please Show ServerKeyExchange signed_params Hash Function #465

Open
jrchamp opened this Issue Feb 22, 2017 · 6 comments

Comments

Projects
None yet
5 participants
@jrchamp
Copy link

jrchamp commented Feb 22, 2017

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

This comment has been minimized.

Copy link

alex commented Feb 23, 2017

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

This comment has been minimized.

Copy link

jrchamp commented Feb 23, 2017

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

This comment has been minimized.

Copy link

jrchamp commented Feb 23, 2017

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

This comment has been minimized.

Copy link

alex commented Feb 25, 2017

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

This comment has been minimized.

Copy link

sigmavirus24 commented Feb 25, 2017

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

This comment has been minimized.

Copy link

davidben commented Feb 26, 2017

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.

@ivanr ivanr added the enhancement label Feb 28, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment