Flag certificate sizes less than 3072 as red or yellow.

[huornlmj]

Which version are you referring to
3.1dev

Describe your feature request (if it's a technical feature)
Flag certificate sizes less than 3072 as red. Current standards are to use cert modulus of 3072 and above. Modulus or cert size of 2048 should therefore be flagged as red or yellow.

[drwetter]

testssl.sh uses red for something which is proven to be broken. That is/was the case for RSA keys with roughly with ~830 bits (2019/2020" https://sympa.inria.fr/sympa/arc/cado-nfs/2019-12/msg00000.html). It is suspected that an attacker with enough resources maybe able to break 1024 bits, using lots of computing resources = time and money.

We can label or flag 2048 bits somehow (either by color or labeling as "deprecated", "not recommended", ...) but we should look at the "current standards" . To which standard were you referring to?

And: if we start using a color here we need to be careful with EC crypto and hash sums too. That somehow needs to be in line.

[drwetter]

And maybe CAs. (https://imirhil.fr/tls/ca.html)

[huornlmj]

Thanks for your feadback @drwetter . Perhaps I didn't formulate my thoughts correctly. Rethinking it, what I think would be a good idea would be a template concept (if such a feature does not exist). E.g., if I could point testssl.sh to a template which states what my specific requirements are for a pass state, then the testssl.sh could be dropped into a CI pipeline which is tailored for a specific TLS hardening profile.

[drwetter]

see #1108 .

TL;DR: doesn't exist yet, that would be cool to have. Needs to be implemented (+ maintained) though.

[drwetter]

As for the 3072 bit and how we label/phrase it, I'd rather listen to @dcooper16

[dcooper16]

As for the 3072 bit and how we label/phrase it, I'd rather listen to @dcooper16

I was also curious about the source of the claim that "Current standards are to use cert modulus of 3072 and above."

I looked at the CA/Browser Forum baseline requirements (https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.4.pdf), and it just specifies that the RSA modulus needs to be at least 2048 bits.

I also tried testing a few servers, including github.com, with testssl.sh, and they all had 2048-bit RSA keys. Looking at the results of some previous testing that I've done I found a few 3072- and 4096-bit RSA keys, but 2048-bit keys were far more common.

If we were looking at NIST guidance, then I think the recommendation would be to

• warn against the use of RSA for key transport (i.e., support any of the TLS_RSA_* cipher suites) with any key length; and
• if the key is only used for signing, (maybe) warn about RSA public keys in certificates that are less than 3072 bits, if the certificate expires after 2030.

[polarathene]

RSA 2048-bit is perfectly fine security wise.

The moment it is not, I am doubtful anything larger is going to help - you'd be better then to migrate away from RSA.

---

FWIW, I had looked into the security strength of 2048-bit RSA keys a while back.

• Assuming 1024-bit was viable to attack, 2048-bit is over a billion times harder (768-bit vs 1024-bit is only a difficulty increase of 1,000 times by comparison).
• The resources required to perform such an attack are so significant that there are far more affordable options available. The energy cost alone would roughly be the equivalent amount needed to boil all of the oceans in the world.
• If you had 100 trillion machines all capable of 1 billion attempts per second (not how this attack works, but simplified), it would still take about 200 years on average ((2^110 / (100e12 * 1e9)) / (60*60*24*365) = 411 years).

---

For most deployments, you're not really gaining anything from 3072-bit RSA keys, just requiring more resources/cost to support it. ECDSA client support is fairly widespread these days (I also looked into that back in 2020-2021, with an in-depth report / analysis I wrote on this topic), I'd advise leveraging ECDSA if you're concerned about RSA 2048-bit (for some business requirements exceeding this size will break support for older software / clients).

I have seen many developers that don't know any better thinking that 1024-bit and 2048-bit sizes look like only double on the surface to them, not a billion times more (symmetric bits, approx 80 vs 110 bits). Worse is those promoting 4096-bit RSA keys for their leaf certs.

It is better for a tool like testssl.sh to reassure what is safe and secure, though I understand if wanting to follow NIST guidelines. Note that NIST does provide a document on how to roughly deriving the symmetric strength, and from that you can reference existing papers on the topic, or go all the way down to reaching the limits of physics and associated information to arrive at the same findings I did.

[grandamp]

Using RSA for key transport seems odd these days, but; not for certificates.

If a key size increase (from a 2k key norm) should be considered, then I have a few questions (if I were responsible for the service):

• What is the recommended usage period for the key size, and;
• Can the relying party community successfully process/validate?

[SSLbrain]

I recently came across the following TLS security guidelines, maintained by the Netherland national cyber security center, due to a reference made by a project we came across to increase internet security in Denmark also in cooperation with the Danish cyber security center. I noticed that Denmark used this, instead maintaining their own standards.

As such it may be useful to use their recommendations, using them as a reference and relying on them to update, we can see they made an update in 2021 increasing their recommendation to use TLS 1.3 as "Good" and downgrading TLS 1.2 to "Sufficient."

https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1

I like their definitions of security levels (see full description in the document, here loosely summarized):

• Insufficient (should not be chosen)
• Phase Out (known to be fragile, possibly needed for compatibility, but may change to Insufficient)
• Sufficient (does the job right now)
• Good (the most secure, future proof)

In this discussion with key sizes, the RSA would be:

• At least 3072 bit is Good (most secure, future proof)
• At least 2048 bit and below 3072 bit is Sufficient (does the job right now)
• Below 2048 bit is Insufficient (should not be chosen)

For ECC keys it lists:

• secp384r1, secp256r1, curve 448, curve 25519 all as Good (most secure, future proof)
• secp224r1 as Phase Out (fragile, possibly needed, may become Insufficient)
• All other Curves as Insufficient (should not be chosen)

I think it is important to show users that do not work with this every day, that Good, does not mean this is the only acceptable level to strive for, but to also educate them that there is a drop in compatibility if you go for the highest levels and sometimes Sufficient could be the better choice when you don't control all clients.

testssl.sh could possibly use the standards, to show a rating for protocol, ciphers, etc. using these terms and using the requirements. At least the definition and discussion on what is good enough, bad or good, is done by someone else, that seem to take the task seriously.

[drwetter]

Difficult topic... Some bits from me

a) NIST says it's good until 2030 (NIST Special Publication 800-57 Part 1, Revision 5, Table 2 and Table 4)
b) If regular RSA keys with 2048 bits aren't fine. Why don't root CA issuers start with their certificates? https://support.apple.com/en-us/HT207189 . (also have a look at the expiration date) or just here: https://imirhil.fr/tls/ca.html
c) https://expeditedsecurity.com/blog/measuring-ssl-rsa-keys/ .
d) Also German Federal Office for Infosec said last year 2048 bit aren't good beyond 2022. Now they relaxed it
(https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-2.pdf?__blob=publicationFile&v=5) a bit. Does that affect RootCAs, too? #LOL

So much for that.

I am not opposed testssl.sh to support different standards. There are always stronger requirements and there will never be a 'one size fits all'. So whatever testssl.sh will do, somebody will complain. ;-)

The best solution would be a template = pluggable rating standard. So, if some one wants to do a compliance scan against PCI DSS, use --template=pcidss, NIST --template=nist, or maybe federal standards just by country code (DE, DK, NL, US, ...)

[drwetter]

The certificate from www.bsi.bund.de (the German Federal Office for Information Security), the intermediate and the Root certificate all have 2048 Bit. And if that's not enough of a smile: the host certificate was recently issued (Mon, 23 Jan 2023)

[polarathene]

At least the definition and discussion on what is good enough, bad or good, is done by someone else, that seem to take the task seriously.

I took it rather seriously when I did an audit and I looked into the symmetric security strength as described earlier, and how viable that was to attack with todays capabilities and to the limits of physics. I also went into NIST guidelines and how they derived their strength based on GNFS, among other efforts.

2048-bit is plenty secure. You're rotating these certs often within 90 day cycles. If there was some technological breakthrough to make 2048-bit insecure, I don't know what makes you think 3072-bit or 4096-bit would be any safer from such a drastic change.

Often those less familiar with the security compare 512-bit vs 1024-bit vs 2048-bit as if it's some linear scale in security strength, it's not. If you are a highly valuable target, you can go beyond 2048-bit if the security margin makes you feel more comfortable, but it's often just for the benefit of those that don't understand much beyond bigger numbers is more secure (this was the case with the three grades of AES being defined: 128-bit, 192-bit 256-bit).

In some contexts, legacy hardware or software is not compatible with anything higher than 2048-bit (some even lower at 1024-bit).

Honestly though, there are more affordable attacks elsewhere. If you need to meet compliance guidelines, do so. Excessive security isn't without its trade-offs.

[drwetter]

I took it rather seriously when I did an audit and I looked into the symmetric security strength as described earlier, and how viable that was to attack with todays capabilities and to the limits of physics. I also went into NIST guidelines and how they derived their strength based on GNFS, among other efforts.

That was very important for those who weren't aware of this. Thanks.

As already said, I won't change the current labeling. This is just another example where compliance and security have ... umm... different stances, to put it this way.

If somebody wants to scan against templates, industry or federal standards, this is what #1108 is for. Once that is working, one can even scan with a template which from the current state of research doesn't make sense. Those templates won't be supported by this project though.