-
Notifications
You must be signed in to change notification settings - Fork 47
Update sslyze branch to NCSC 2025 #1800
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
base: sslyze
Are you sure you want to change the base?
Conversation
|
Regarding SHA2 key exchange: TLS 1.2 still supports signature algorithms here that do not meet the new requirements. So, we need to keep the check, but modify it from "you must support SHA2" to "you must not support any SHA1 or MD5". In TLS 1.3, only SHA2 is supported for this purpose. |
98ace1a to
ac3edcc
Compare
faeba8d to
3b59db8
Compare
e46af94 to
63c8ff9
Compare
ad38aec to
8b418e4
Compare
…and older, sha224 to phase out). Note labels have changed slightly.
…tates now, also requires new labels see categories.py
…lines, so status fail and score penalty seems fitting
|
I've been running extensive comparisons to #1218 on websiteregister and a few hundred other names. Based on this, we need to do some more thinking on how we apply the new requirements and checks. We don't have great tools to analyse in bulk, but regular issues seem to be cipher selection and cipher order. This adds up, as we bumped a lot more ciphers to phase out, so that makes cipher order stricter. Some failures of key parameters, for DH-2048. Warnings for RSA-2048 are pretty common too. Unacceptable TLS versions seem rare in our set. These are all reasonable: we expect new failures, and they are fixed by correcting cipher settings in the TLS config. Certificate replacement is more work, especially as we count intermediates too, but RSA-2048 has no score impact. The tricky areas are properties of the TLS stack. They can not just be ticked on and off, it requires software updates/replacements update: it may be possible to fix some of this with OpenSSL security levels. There are three that are pretty common failures: EMS, RSA-PKCS and SHA1. These tests are all ❌ if not met and therefore have score impact. And, perhaps there are bugs in the test - this is not a widely covered area by other testing tools. They are in part common because many Dutch government websites use Akamai, which appears to allow SHA1 and not support EMS For example: ondernemersplein.kvk.nl, papiamentu.rijksdienstcn.com, intermediair.nl, rijkswaterstaat.nl, adviescollegeregeldruk.nl, www.nza.nl, healthcouncil.nl, sodm.nl, www.open-overheid.nl. Note that in a fair number of cases, only the www/no-www version is Akamai, and the other direct to webserver. However, this isn't unique to Akamai - @bwbroersma's b6a.nl supports RSA-PKCS for example. Extended Master SecretThe origin of our requirement for EMS (an extension in TLS 1.2, irrelevant for 1.3) comes from RFC9325 3.5 which makes it a MUST, and the NCSC 2025 guidelines where it's a soft mention in a sentence. It seems that at least a significant part of Akamai's CDN does not support EMS. I have good confidence in our test, it's just checking for the presence of the EMS extension in ServerHello if the target supports TLS 1.2. So far, testssl.sh has been entirely consistent with us. SSLLabs does not test this. Key exchangeTLS key exchange uses a signature/hash algorithm. Note that this is not the ciper suite, and not a property of the certificate. Defined in RFC5246 7.4.1.4.1 for 1.2, RFC8446 4.2.3 for 1.3. Common for both is that we use set1_sigalgs to limit the connection to a set of "bad" sigalgs, then try to make a TLS 1.2 connection (irrelevant on 1.3, and <1.2 is bad anyways). From tcpdumps, I am certain we are sending the extension correctly. SSLlabs does not test this, testssl so far has been consistent with us. SHA1 in key exchangeNCSC 2025 guidelines 3.3.5 class SHA1 as "onvoldoende". We test for SHA1 by setting the signature_algorithms extension in our ClientHello to only SHA1 options with EC/RSA/DSA. If a connection is established, we might assume the server allows SHA1, therefore, bad result. However, apparently we have found servers in the past (no specific source available) that would ignore our signature_algorithms, use a good SHA2, and our OpenSSL would accept it, as it does actually know about SHA2. Therefore, we also check get_peer_signature_nid to make sure it's in the bad list. If so, we presume SHA1 is enabled. I think testssl does the same thing, but possibly without the extra check. RSA paddingThere are two padding methods for RSA: PKCS#1 v1.5 and PSS. Originally TLS 1.2 only supported PKCS. RFC8446 (for 1.3) extends RSA-PSS support to TLS 1.2. NCSC 2025 guidelines class PKCS as "onvoldoende" Essentially, we use the same method as for SHA1. In the current implementation, the cross-check of "if the connection was established, also check what was actually negotiated" is missing, because I overlooked the SSL_get_signature_type_nid call in OpenSSL that will probably allow this (will have to get added to nassl). Though we do not currently have any false positives, so this may be superfluous. ConclusionsWe should consider carefully, in the context of this data:
Likely confirmation of Akamai's settings:For RSA-PKCS, it would be good to have/quote sources beyond NCSC. |
23a05f6 to
6b9d4a2
Compare
Add test for resumption (3.4.3)no new test, this is covered by TLS version checkInteresting data point: the old SHA2 key exchange check had a bug in the sslyze branch, which we did not notice in comparisons probably because it never fails.
Weird results
Discuss:
To consider
Content
See content PR