GeezerVison is showing github.com — Review the various colour coding in sslscan · Issue #333 · rbsec/sslscan
Review the various colour coding in sslscan #333DescriptionSslscan uses colour coding in its output to indicate security concerns (or not) for various things. A probably incomplete list:
Red Background - really bad stuff
Red - known vulnerabilities that are somewhat exploitable
- Weak or broken crypto
- MD5 or SHA-1 certificates
- RSA certificate keys <2048 bits or EC keys < 112 bits
- Self-signed or expired certificates
- SSLv2 and SSLv3
- Key exchange groups < 112 bits
- MD5 or DSA signature algorithms
- TLS Compression
- DHE keys <= 768 bits
- Ciphers <=56 bits
Yellow - Concerns without known vulns, or weaknesses that are not generally considered feasible to exploit
- EC keys <128 bits
- RSA keys < 2048 bits
- DHE keys <= 1024 bits
- Ciphers < 112 bits
- 3DES and RC4 ciphers
- CCM8 ciphers
- SM4 and GOST ciphers (developed by hostile governments)
- TLSv1.0 and TLSv1.1
Purple - unusual, so should stand out
Green - good things that are currently best practice.
- GCM and CHACHA2020
- TLSv1.3
- SHA-256 or SHA-512 certificates
- RSA keys > 3072 bits
- Ciphers >= 128 bits
- Key exchange groups > 112 bits
White
These are somewhat arbitrary, and many of them haven't changed or been updated for some time, as noted in #331 . That doesn't necessarily mean that they're incorrect - but it's probably worth reviewing them and thinking about whether they still stand or should be updated, and whether they're consistent.
One thing that I'm conscious of is that there are people and organisations who interpret the output of scanning tools like sslscan as gospel, where "red = must fix", rather than performing any kind of analysis or risk assessment. As such, if we are flagging things as red then I want to make sure that we have a solid reason to do so. Activityjtesta commented on May 26, 2025 Thanks for starting this thread! Some notes:
- NULL ciphers and anonymous ciphers are categorized differently. If I'm understanding "anonymous ciphers" correctly, that means signatures on the key exchange aren't verified, so MITM is possible, right? I suppose there is a practical difference between the two, since the second case requires an active attack (MITM) vs. just passively reading plaintext messages (NULL ciphers), but... they're both terrible. Perhaps just to make things simpler for the users, they could be displayed the same.
- DHE keys <= 768 bits (red): I'd support expanding this to <= 1024.
- DHE keys <= 1024 bits (yellow): could be <= 2048.
- Ciphers <= 56 bits (red): could be < 112.
- Ciphers < 112 bits (yellow): could be < 128.
- EC keys < 128 bits (yellow): Is this raw key size? If so, 128 bits is equivalent to 64 bits of symmetric strength (!).
- RSA keys < 2048 bits (yellow): could be <= 2048.
- SM4 and GOST ciphers (developed by hostile governments) (yellow): I'd support making this red, along with any algorithms developed without transparent processes and without input from the open cryptographic community. "Hostile governments" is pretty relative, and I'd still have a major problem if a "friendly government" developed anything in secret.
- Missing from the list seems to be SHA-1-based ciphersuites. I'd support them categorized as red along with SHA-1 certificates.
Like I said in the other thread, I'd support marking the NIST P-curves (P-256 / secp256r1, P-384 / secp384r1, P-521 / secp521r1) as red to match the SM4 & GOST algorithms. I have a lot to say about this topic, but before I go off and write 18 paragraphs, perhaps I'll see what you think of it first. And see if you're even interested in discussing it.
The suggestions I made above are roughly in line with what the ssh-audit tool reports. I haven't heard any complaints about its ratings in the years I've managed it.
Also, perhaps when this process is done, we could document the rationale in the README. I've also daydreamed about adding a section in the tool's output for giving that rationale directly to the users in realtime (much like how ssh-audit does). That would be ideal for usability, but a challenge to implement in C. Not impossible, though. rbsec commented on May 26, 2025 I've not really put much thought into any changes myself, but seemed worth making a thread while I remembered. I'll need to go back through that list and have a think. But regarding your comments:
NULL ciphers and anonymous ciphers are categorized differently. If I'm understanding "anonymous ciphers" correctly, that means signatures on the key exchange aren't verified, so MITM is possible, right? I suppose there is a practical difference between the two, since the second case requires an active attack (MITM) vs. just passively reading plaintext messages (NULL ciphers), but... they're both terrible. Perhaps just to make things simpler for the users, they could be displayed the same.
The logic behind this was that there are some legitimate uses for anonymous ciphers, because when you have no PKI or certificate verification then they're effectively as good as any other ciphers, and there were some cases such as SMTP servers where they were getting enabled by default and even being recommended. So I wanted them to be highlighted as something really unusual, which would encourage people to look into them and think about whether they should really be there.
NULL ciphers are almost universally bad - the only legitimate use of them I've never seen is in Microsoft DirectAccess, but they occasionally get enabled on other stuff. Pretty sure I saw them on an RSA "secure" appliance once, where they just seemed to have enabled every possible cipher.
So I think there is some meaningful difference between them from a security perspective; but since they're both very rare then perhaps it makes sense to combine them.
DHE keys <= 768 bits (red): I'd support expanding this to <= 1024.
DHE keys <= 1024 bits (yellow): could be <= 2048.
So that would give us:
- 1-1024 bits = red
- 025 to 2047 bits = yellow
- 2048+ bits green
Slightly odd to miss the white option, but then 4096 bit DHE keys are probably excessive.
Ciphers <= 56 bits (red): could be < 112.
Ciphers < 112 bits (yellow): could be < 128.
I don't think that there are any normal ciphers between 56 and 112 bits, so this would effectively give us:
- 0 bits (NULL) = red background
- 1 to 111 bits = red
- 112 to 127 bits = yellow
- 128+ bits = green
The main difference been the the 112 bits (3DES) ciphers are now have a yellow bit strength, rather than just a yellow cipher name - which seems sensible.
EC keys < 128 bits (yellow): Is this raw key size? If so, 128 bits is equivalent to 64 bits of symmetric strength (!).
It's the effective symmetric key strength in the certificate output:
// We divide by two to get the symmetric key strength equivalent; this
// ensures consistency with the Server Key Exchange Group section.
int keyBits = EVP_PKEY_bits(publicKey) / 2; So it's really:
This would effectively change 2048 bit certificates from white to yellow, and we currently have 3072+ bit keys as green.
Given that organisations like NCSC and NIST are still recommending 2048 bits with RSA (up until least 2030 in NIST's case), I'm not sure about warning on this yet. In a couple of years, or when people are more generally recommending bigger keys with RSA (or just not using it), then that would seem more reasonable.
SM4 and GOST ciphers (developed by hostile governments) (yellow): I'd support making this red, along with any algorithms developed without transparent processes and without input from the open cryptographic community. "Hostile governments" is pretty relative, and I'd still have a major problem if a "friendly government" developed anything in secret.
This is a bit of a can of worms, and given that it has a regional and geopolitical angle, I'm slightly hesitant to make sslscan too anglocentric, especially as that feels somewhat against the open source ethos.
I don't think I've ever seen either of these ciphers in a real environments, but I'm sure that's not the case for everyone, and some people are probably seeing these in every test that they do. However, if I did see them then that would definitely be something that would need to be highlighted and investigated, and would probably greatly upset some people (like when I found Notepad-- on a client system).
I almost wonder if this is a good use of an unusual colour (perhaps taking over purple from anonymous), as a way of flagging something that is not necessarily bad, but that needs to stand out and be investigated. But changing the meaning of colours is not ideal.
But if I ask myself the question "Would I be more concerned to see a client using GOST than I would to see them using RC4?", the answer is definitely yes - which seems to be reasonable grounds for making them red.
Missing from the list seems to be SHA-1-based ciphersuites. I'd support them categorized as red along with SHA-1 certificates.
SHA-1 certificates are already flagged as red. As for the ciphers, SHA-1 certainly it's something that we'd want to actively encourage (none of them are green), but given how it's being used in a HMAC construct, as far as I'm aware there isn't really any realistic exploit against it. I could perhaps see an argument for warning on it (yellow); but sticking these ciphers into the same "never use these" bucket as the things like EXPORT ciphers.
This is going to be a big chunk of the detected ciphers on a lot of sites though, and means that there's going to be very little white left in the output.
As for the discussion about NIST related stuff....it's a complicated question, and one that has not just technical and cryptographic angles, but there's also some wider considerations about what the outcome of making those changes might be, and what message that's sending.
I need to have a proper think about this, and pull my thoughts together into something coherent - so bear with me and I'll post something more once I've had time to do so. jtesta commented on May 27, 2025
Given that organisations like NCSC and NIST are still recommending 2048 bits with RSA (up until least 2030 in NIST's case)
My practical concern with 2048-bit RSA is in the case of patient health information (PHI). Five years is way too short to ensure strong confidentiality of that type of data. In fact, even security ~90 years into the future might not be enough, if breakthroughs in medicine cause people to live longer (or even MUCH longer...). For that reason, I've encouraged 3072-bit/effective 128-bit security as the baseline for all systems for the last 10+ years. I have rarely gotten pushback on that.
I don't think I've ever seen either of these ciphers ("SM4", "GOST") in a real environments
Alibabacloud.com uses curveSM2, I noticed. And I heard that the Chinese government is mandating more use of their home-grown algorithms. So these algorithm groups may be heavily used in China/Russia. I don't have any metrics at the moment, though.
This is going to be a big chunk of the detected ciphers on a lot of sites though, and means that there's going to be very little white left in the output.
I don't particularly see this as a problem. In the SSH world, there are many less-than-ideal defaults. I've taken the approach of always highlighting them to the user and letting them decide how they want to handle it. rbsec commented on May 31, 2025
My practical concern with 2048-bit RSA is in the case of patient health information (PHI). Five years is way too short to ensure strong confidentiality of that type of data. In fact, even security ~90 years into the future might not be enough, if breakthroughs in medicine cause people to live longer (or even MUCH longer...). For that reason, I've encouraged 3072-bit/effective 128-bit security as the baseline for all systems for the last 10+ years. I have rarely gotten pushback on that.
I think encouraging 3072 or 4096 bit RSA is reasonable - and I think that we're doing that with making those green. But I'm less sure that warning against 2048 RSA - because in the general case I don't really think that there's an issue with it. There are certainly environments where it might not be wanted (or RSA might not be used full stop); but if they have those kind of bespoke requirements and threat models then they should be making their own decisions about these things.
Once we're there's a general recommendation against 2048 (or we get within a few years of NIST saying to stop using them) then we should probably start warning against them. But if you need to try and protect data over a multi-decade period then that requires some major rethinking - I wouldn't bet on 3072 bit RSA being enough in a couple of decades, let alone if you're concerned about a 90 year period (which is longer than Colossus to the current day).
I don't particularly see this as a problem. In the SSH world, there are many less-than-ideal defaults. I've taken the approach of always highlighting them to the user and letting them decide how they want to handle it.
I don't think I necessarily have a problem with this, but it does kind of raise the wider question about what white colouring (or more strictly, the absence of colouring) means in the output. If green is "good" and yellow is "not ideal, but not exploitable" then I'm not really sure what's left in the gap. rbsec commented on May 31, 2025 Right, so I've been having a think about the handling of the NIST curves. I know that some people have concerns about curves like P-256, and suspicions about a NIST backdoor. And it's a debate that can go on forever - because unless someone finds evidence of an actual backdoor then it's really all just speculation.
So I'm going to try and sidestep that and approach this with my consultant hat on.
NIST recommend using these curves - but then they would. Some people trust NIST, and some people don't, especially based on their past behaviour. And the USA is certainly moving into the "hostile nation state" category for most of the world, and will continue to do so for at least the next few years.
But it's not just NIST who are recommending it. In the UK, we have NCSC who provide a similar role, and they recommend it in their guidance. And it's not just the USA and UK. The French equivalent of NIST also seem to recommend it (although their guidance is a few years old). The Indian government recommend it. I imagine that there are also plenty of other governments - but if I spoke any languages other than English that would be a lot easier to check. And Mozilla recommend it in their modern settings.
Which means by going directly against their recommendations and saying "these curves are bad and should not be used", then I'm either saying:
- I think that the national technical authority for the UK (another others) are incompetent, and that I know better than them; or
- I think that the national technical authority for the UK (and others) are deliberately recommending that UK businesses and government departments use backdoored crypto.
And those are pretty difficult positions to defend, when all that you can really point to is speculation, most of which ultimately comes down to "we don't trust NIST". If there were some peer reviewed papers about this, or respected organisations of the same sort of calibre recommending against it with strong justifications then that might be a bit easier - but I'm not really aware of any.
Which means sooner or later running into the question of "why is your scanning tool saying that this is insecure and should not be used, but you're recommending that we follow NCSC/Mozilla/whoever guidance?", and then going down the rabbit hole of the online debate about it.
And I'm definitely biased here, due to the environments that I work in. But that's always been true for sslscan - there are plenty of people who would consider GOST or SM4 to be far more trustworthy that anything that NIST or IANA or IETF have been involved in. And there are people who consider all ECC to be questionable due to how involved the NSA has been in it as a field.
Anyway, I think that where I'm going with this is that sslscan is a tool that's used by a lot of people, including both security testers and also people from the sysadmin/blue team side, some of whom will make decisions based on its output. And although some of the classifications that we give to the various ciphers/etc are slightly arbitrary in places, they should be supported by some real evidence about the security issues that we're highlighting. I have plenty of my own personal views about many areas of security, including the extent to which various organisations can be trusted to be both competent and non-malicious - but they're just that, personal views.
And while those shape my own actions and how I might build and configure my own systems, I try not to let those impact on my professional role unless I have something solid to substantiate them, or I'm talking OTR to someone and make it clear that they are my own views.
Where we flag RC4 ciphers, or TLSv1.0, or 1024 bit RSA, I feel like we can point to robust evidence from respected authorities about why those are bad (even if they may not be easily exploitable). But I'm not really convinced that I can do that for the NIST curves. I can certainly point to some long arguments about them online, and the various claims that people make about magic numbers and suchlike - but I don't think that I would want to try and have that argument with a CISO/SIRO/etc.
And you could make a similar argument about GOST/SM4 - but I think the key difference there is that there's not really anyone outside of the Russian and Chinese governments who recommend those. If Mozilla and lots of other countries' technical authorities were recommending those as well, then that would be different.
I realise that this has been a slightly unstructured stream of consciousness, but hopefully it's somewhat coherent and makes some kind of sense. jtesta commented on Jun 1, 2025 Ok, so I suppose the NIST P-curves will stay the way they are.
In terms of SHA-1-based ciphersuites, shall those be marked in yellow, then? It seemed that you might be leaning that way. (I'd be happy with that, myself.)
How do you feel about classifying algorithms developed by governments without much public input, such as SM4 & GOST? It almost sounded like you were considering marking them red. (I'd prefer red, myself, though its your call as maintainer!) rbsec commented on Jun 3, 2025 I don't have particularly strong feelings either way for the SHA-1 ciphers. They're not really exploitable; but then I suppose on the other hand there isn't really any reason why you should be using them nowadays other than for legacy clients - so perhaps that's enough grounds to flag them in yellow.
We'd probably want to look at what's left white then - I think that would mostly be SHA-256/384 ciphers that aren't both GCM and DHE?
For SM4 and GOST, I think I'm happy for those both to go red. I'm sure some people in other countries would disagree, but if I ever seen one of those on a client system I'm testing it will definitely be a "WTF are you doing?" type discussion.
Does that sound reasonable? jtesta commented on Jun 3, 2025 rbsec commented on Jun 7, 2025 @jtesta I've made some changes in 0d8511a based on the discussions above - although I may have missed or forgotten something.
Not fixed up all the docker tests yet, but wanted to make sure all the changes are done before spending time on that. I also noticed that we weren't flagging MD5 ciphers (like TLS_RSA_WITH_RC4_128_MD5), so included those. jtesta commented on Jun 7, 2025 Ok, I'll take a look!
And in terms of the Docker tests, you don't have to worry about those.
I was already planning on adding more tests soon since the existing
ones run against old versions of OpenSSL and GnuTLS; we need to expand
them to run against newer targets as well. So I'll go ahead and fix
whatever broken tests there are while I'm at it. rbsec commented on Jun 12, 2025 @jtesta I assume that you're happy with these changes, and that I've not missed anything obvious or messed any of them up? If so I'll get #336 merged and then I think we're got to tag a 2.2.0 release. fredrikhesse commented on Sep 18, 2025 Hi! Would it be possible to add a late addition to this thread?
Right now, color-coding/strength is not consistently being exported to the xml, this would be very beneficial.
(For example ciphers include strength, but groups does not, even though it does on the console) rbsec commented on Oct 12, 2025 @fredrikhesse not including the strength output in the XML for groups was just an oversight, which I've fixed in 35cd5f9. I'm not able to build a new version now, but next time I do that'll be included (or you can just build from source).
I'll have a think about where else it should go as well - I think the main other area might be the TLS protocol versions.
Thanks
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|