-
Notifications
You must be signed in to change notification settings - Fork 239
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
Not reporting Key Exchange
100 score with EC 384 bits
#935
Comments
I wonder if it's your "Supported Named Groups" setting (currently "x25519, secp256r1, x448, secp521r1, secp384r1"). See if changing it to just "x448, secp521r1, secp384r1" helps. |
Thank you for the suggestion! Disable x25519? I cannot find anything negative on x25519. Why should that be disabled? But arguments were made against secp / NIST. By comparison, https://www.ssllabs.com/ssltest/analyze.html?d=dustri.org reports:
In conclusion, bug is probably not preventing |
nginx config.
Causes ssllabs HTTP error. I cannot find any TLS hardening documentation advising to change nginx config
Did you mean try to disable |
or
results in ssllabs:
But still only https://serverfault.com/questions/877774/trying-to-get-100-in-ssllabs-com-key-exchange from 2017 is saying:
But it seems that might have changed meanwhile or it's a different issue. |
Do you know any server on the internet that is using EC 384 bits (SHA384withECDSA) that has |
I’m also against disabling |
I meant try to disable both |
I don't want to do this for the sake of ssllabs would need to provide guidance (if that is their opinion, what I doubt) or fix this bug (seems like a bug, appropriate to fix). However, it seems like there's a lot of issues posted on this ssllabs issue tracker for some time now with little to zero replies or action from ssllabs. So it seems kinda deprecated. Hope to be wrong on this one as it would be sad to see ssllabs becoming less useful over time. |
I think they want a 256-bit security level to give you a 100%, but those only have 128-bit security levels. |
It is impossible to achieve 100% if using TLS 1.3 as the standard mandates that you enable support for AES-128 (TLS_AES_128_GCM_SHA256). Just because you can’t achieve 100% doesn’t mean it isn’t a secure setup - it is still classified as A+. Disabling x25519 Key Exchange just to achieve 100% would be a bad idea. |
Just because the standard says something is mandatory doesn't mean you can't turn it off anyway. Plenty of Web servers will let you do so. Also consider that the TLS 1.2 standard mandates you enable support for TLS_RSA_WITH_AES_128_CBC_SHA. |
Chris Mason:
It is impossible to achieve 100% if using TLS 1.3 as the standard mandates that you enable support for AES-128.
These have already been disabled.
|
I've done a lot of experimentation with the scanner & identified the most permissive set of ciphers and curves that will still earn all 100% these are in Apache format but it shouldn't be a big deal to convert for other webservers
|
Yes, here is my test-domain using EC384 and 100% score on everything and A+: https://www.ssllabs.com/ssltest/analyze.html?d=goldhammer.se I wrote an article about the configuration some months ago: |
Confirmed. Using: |
https://www.ssllabs.com/ssltest/analyze.html?d=whonix.org
#650 (comment) @josephcsible
The server is already using EC 384 bits.
Bug: Still only a 90%
Key Exchange
score.The text was updated successfully, but these errors were encountered: