Open adrelanos opened 1 year ago
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:
Key Exchange
: 100
% scoreHSTS Preloading
: Not in: Chrome
Supported Named Groups
: secp384r1
In conclusion, bug
is probably not preventing Key Exchange
100
score on my server.
nginx config.
ssl_ecdh_curve x25519:x448;
Causes ssllabs HTTP error.
I cannot find any TLS hardening documentation advising to change nginx config ssl_ecdh_curve
or disabling any curves that are part of the TLSv1.3 standard.
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.
Did you mean try to disable secp256r1
?
ssl_ecdh_curve x25519:x448:secp521r1:secp384r1:secp256r1;
or
ssl_ecdh_curve x25519:x448:secp521r1:secp384r1;
results in ssllabs:
Supported Named Groups x25519, x448, secp521r1, secp384r1 (server preferred order)
But still only Key Exchange
90
% score.
https://serverfault.com/questions/877774/trying-to-get-100-in-ssllabs-com-key-exchange from 2017 is saying:
The rating guide doesnt say, but i was able to confirm that you cannot get rating 100 if your server prefers
secp256v1
(equivalent to 3k bits RSA) while offering ECDHE ciphers that could be usingsecp384v1
(equivalent to 7k bits RSA).
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 Key Exchange
100
% score on ssllabs?
I’m also against disabling x25519
, but if you want to score 100 % on SSL Labs you will need to. Indeed, it’s a ~256bits curve, so SSL Labs grad it 90 %, but that is pointless.
Did you mean try to disable
secp256r1
?
I meant try to disable both x25519
and secp256r1
.
I don't want to do this for the sake of Key Exchange
100
% score at ssllabs. At least not without a strong rationale such as x25519 and/or secp256r1 being considered weak, which doesn't seem to exist at this point.
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.
It is impossible to achieve 100% if using TLS 1.3 as the standard mandates that you enable support for AES-128
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
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-CCM:DHE-RSA-AES256-CCM8:ECDHE-ECDSA-AES256-CCM:ECDHE-ECDSA-AES256-CCM8:DHE-RSA-ARIA256-GCM-SHA384:ECDHE-ECDSA-ARIA256-GCM-SHA384:ECDHE-ARIA256-GCM-SHA384
SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
SSLOpenSSLConfCmd Curves sect571r1:sect571k1:secp521r1:brainpoolP512r1:sect409r1:sect409k1:brainpoolP384r1:secp384r1:X448
Do you know any server on the internet that is using EC 384 bits (SHA384withECDSA) that has
Key Exchange
100
% score on ssllabs?
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: https://www.linkedin.com/pulse/configuring-pfsense-firewall-haproxy-maximum-security-goldhammer/
Do you know any server on the internet that is using EC 384 bits (SHA384withECDSA) that has
Key Exchange
100
% score on ssllabs?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
Confirmed. Using:
Supported Named Groups
: secp384r1
https://www.ssllabs.com/ssltest/analyze.html?d=whonix.org
https://github.com/ssllabs/ssllabs-scan/issues/650#issuecomment-419498038 @josephcsible
The server is already using EC 384 bits.
Bug: Still only a 90%
Key Exchange
score.