Update warnings & failures

[jtesta]

I think some algorithms & key sizes should be re-categorized. Instead of just issuing a PR, I thought I'd talk about it first and see if we are on the same page.

1. Non-DH/ECDH cipher suites should be marked as warnings (i.e.: colorized yellow). These do not afford the property of Forward Secrecy, so a server compromise can divulge past communications. Here are some examples (notice that they do not have DHE/ECDHE in their names):

AES256-GCM-SHA384
AES256-CCM8
AES256-CCM
AES128-GCM-SHA256
AES128-CCM8
AES128-CCM

2. Flag any SHA-1 cipher suites as warnings. Currently, sslscan does not colorize the following:

ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
AES128-SHA
AES256-SHA

3. Flag anything at the 112-bit security level as a warning. According to this NIST document (see pg. 54 & 55), this includes 2048-bit RSA & DH. I base this on (admittedly, a bit out-dated) research from 2003 that suggested 2,048-bit provides security only until the year 2030; this would be insufficient for some things such as patient health information. I do recognize that an updated estimate would be more convincing, but note that the NSA recommends 3072-bit for TOP SECRET data. To some people, their health information is indeed very sensitive, and must be protected for decades into the future. A 128-bit level would give a more comfortable buffer for this scenario.

4. Flag anything using the NIST P-curves (P-256/384/521) as a hard failure. I'm part of the camp that strongly suspects these were back-doored by the NSA in the late 1990's. I actually gave an hour-long presentation on this topic before, so I have a lot to say about it (the ultra-short summary is that magic numbers were used with no rationale given, NIST refuses to comment on them, and the NSA got caught red-handed in the Snowden leaks pushing NIST into standardizing the Dual_EC_DRBG random number generator with a back-door). But instead of writing pages and pages here, I'd first see where you are on this topic. I'd be happy to elaborate if you're not convinced. (FYI: substituting the P-curves with Curve25519/Curve448 yields no performance nor compatibility problems in modern browsers.)

Thoughts? I'll be happy to submit PRs for these if you're on board.

[rbsec]

Non-DH/ECDH cipher suites should be marked as warnings (i.e.: colorized yellow). These do not afford the property of Forward Secrecy, so a server compromise can divulge past communications.

This seems reasonable. It would also be nice to have another colour to indicate non-PFS ciphers, but I don't think that's really going to work, so flagging them yellow might be the best option. It would probably also be good to add a new XML elements fo pfs="no" or something like that, so it's clear from the XML why they were flagged.

Flag any SHA-1 cipher suites as warnings.

Also seems reasonable - there's no reason to be using SHA-1 in 2020.

Flag anything at the 112-bit security level as a warning. According to this NIST document (see pg. 54 & 55), this includes 2048-bit RSA & DH.

Flagging up 112 bits seems fair enough (AFAIK the only cipher with this strength is 3DES, and we're already flagging the cipher in yellow, so flagging the bits in the same colour seems sensible). However, I'm a bit more uncomfortable with the idea of flagging everything 2048 bit as a warning (even though they're arguably the same strength).

The current recommendations from NCSC are to use 2048 bit certificates, Mozilla recommend it when you can't use EC certificates, and NIST recommend it for normal usage (although with the caveat you mentioned about using 3072 for TS).

I think it's hard to justify going against the recommendations of organisations like that without some pretty strong justification, and some good references to point to. I think that the current behaviour of displaying 2048 in white (i.e, "fine, but not the best"), and 3072 and above as green (was previously 4094 and above, but that should really have been 3072, so I fixed it in 1495e4f) seems like a reasonable approach for now. Happy to discus further.

Flag anything using the NIST P-curves (P-256/384/521) as a hard failure.

This is an....interesting area. I'm aware of some of the arguments around these curves (although not in anywhere near the depth that you've clearly studied them). Without wanting to go too deep into the technical side of this, I think the main question would around the purpose of sslscan and the wider context.

These curves have been implemented by pretty much everyone, and are recommended by quite a few people (such as NCSC and Mozilla) other than NIST. By flagging them as insecure, we're saying that either all of these organisation are wrong and have implemented backdoored cryptography (i.e, we know better than Mozilla, Google, Microsoft, NCSC, etc) or that they are all part of an conspiracy to deliberately implement backdoored cryptography (including organisations outside of the USA, who are recommending it to their own government departments and companies).

If I'm reporting this as an issue to a client on a penetration test, this then puts me in the position of either saying "I know more about crypto than our government" or "our government is intentionally recommending you use backdoored crypto that lets the USA spy on you because....reasons". Neither of those really seem like a position that I want to be in. We do flag some of the Chinese and Russian ciphers as questionable, but that's a much easier argument to have, and they've also received a lot less scrutiny (in public anyway, I'm sure certain organisations have spent a very long time looking at them).

To draw a parallel, there are a lot of reasons to suspect that certain organisations might have backdoors in Microsoft Windows, and definitely have access to platforms such as Azure. However, I don't think it would be appropriate for a scanning tool to throw a warning based on the fact that someone was using Windows, unless there is some concrete evidence of an actual backdoor that affected them.

The current code displays these curves in white (i.e, "fine, but not the best") rather than green - which seems like reasonable position. We're not actively saying "this is bad", but we are saying "there's a better option available". Although actually, looking at the code, secp256k1 is flagged in green - I wonder if that should change? Ignore that, mixing up my curves.

Interested to hear your thoughts on the above.

[adrien-n]

Hi, IIUC TLS 1.3 ciphersuites are not being rated as strong since the key exchange is specified elsewhere and "DHE" never appears in the cipher name. They still appear as "acceptable" but this makes the ranking surprising.