Sslscan uses colour coding in its output to indicate security concerns (or not) for various things. A probably incomplete list:

Red Background - really bad stuff

• NULL ciphers

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

• Anonymous ciphers

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

• Everything else

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.