Confused about TLSv1.2+TLSv1.3 vs. TLSv1.3 only.

[jsuelwald]

Hi,

currently my server achieves 100% rating everywhere and A+ with TLSv1.2 and TLSv1.3 enabled. If i disable TLSv1.2: 100% everywhere, but only "A" as Rating.

What's wrong there?

[ArchangeGabriel]

Might be because it can’t test FALLBACK in this case.

[jsuelwald]

Ok, let me ask this another way:

Is it possible to Achieve A+ with TLSv1.3 only? And: I consider this result (everything at 100% and still "only" A as a fault.

[polarathene]

@jsuelwald you were advised that it was probably due to the check for TLS_FALLBACK_SCSV.

See the grading guide for the test here:

Don’t award A+ to servers that don’t support TLS_FALLBACK_SCSV.

When you only support one protocol version, that will fail to my understanding. Perhaps the test could find a way to detect that and avoid the grade cap? The grade given is only meant to be a rough guide.

You can try manually check the support yourself with openssl. Should confirm if that's the cause for you.

[naumanshah03]

Issue related to #711

[annainfo]

When will this bug be fixed? Not providing TLSv1.2 doesn't make a server less secure. And worse, servers with 90% Key Exchange and 90% Cipher Strength can get A+, while a TLSv1.3 only having 100% in each of the four categories only gets A.

[ammnt]

I suggest just adding "S" grade with only TLS 1.3, strong ciphers, HSTS and a key length of 4096. Something like that🤔Because now the "A" grade is aimed at compatibility, not the security level, i think.

[polarathene]

a key length of 4096

That is excessive. 3072-bit RSA already provides at least 128-bit of symmetric security strength. To attack that would use so much energy that all of the oceans on Earth would be boiled and evaporated into steam IIRC. I mean sure, 4096 is more difficult than that, but it makes no practical difference.

2048-bit RSA which provides roughly 112-bit symmetric security strength is not ocean boiling capable, but it's still very out of reach. The global bitcoin network achieved a hashrate of 150 million TH/sec as a reference which is a very large amount of compute resources, if that was equivalent to a brute-force rate against 2048-bit RSA it would take over a billion years (where the Sun is responsible for evaporating our oceans as it's heat output increased).

1024-bit RSA however is generally rated at a much lower 80-bit symmetric security strength. That same bitcoin hashrate reference would on average (half the time) have success within roughly an hour. Yet so far, to my knowledge no one has managed to factor 1024-bit RSA, it's more than just compute power, there are resource requirements that bottleneck pulling it off.

The sheer cost of attacking 2048-bit RSA time aside already makes it not worthwhile to perform on most targets. At 4096-bit RSA, some Certificate Authorities (CAs) will use this; however if you decide to as well, the attacker only needs to attack the CA instead which is a more valuable target (they can sign certs as if they were the CA, thus all sites that used the CA for a cert).

---

Advising 4096-bit RSA is often someone just doubling 2048 out of habit without understanding the why, if anything it's lazy security. Depending on your demographic/load, you're introducing more CPU overhead and bandwidth for very little pragmatic value.. if any.

If you want to feel safer by offering higher numbers for security, go with ECDSA and P-384 (192-bit symmetric strength, more than 4096-bit RSA), but P-256 would be adequate and preferably imo.

[h1z1]

Ran into this with a client, fun times..

IMHO the test and rating are valid. You should not be able to manipulate it by limiting what is tested and what isn't.

For the same reason determining what cipher or even what curve is more "secure" then another, the rating should reflect a spec baseline with little politics arbitrary data points as possible.

It's a pragmatic validation and helpful one, but not dogmatic.

[catharsis71]

Two years later it's still impossible to get an A+ with a TLS1.3-only setup

This decision really needs to be revisited. Whatever the original reason may have been, it doesn't make sense that in 2022 we still have to enable an obsolete, less-secure protocol in order to get an A+

Will this still be the case in 2025? 2030? Someday having TLS 1.2 enabled will be considered a serious security flaw -- when that day comes, then will you reconsider?

With Internet Explorer reaching end-of-life soon I'm seriously tempted to ditch TLS 1.2 on all my sites, but the rating punishment makes me hesitate.

[Harpolean]

How is this still not resolved. Being punished for disabling TLS 1.2 and only running 1.3 doesn't make sense, especially when overall it is encouraged to adopt and support 1.3.

[polarathene]

it doesn't make sense that in 2022 we still have to enable an obsolete, less-secure protocol in order to get an A+

You don't have to.

Why would you do that just for an "A+" rating? Use it as a rough guide instead of chasing after a top rating. It's a tool, not something that's required for proper compliance.

A high rating is good, but the main purpose is be aware of what is marked down, and the why. You landed here, and know that it's not something to worry about :+1:

---

It makes no real difference if this is ever addressed. Other than boasting or convincing others that don't understand the technical reasons that you've delivered the "best" security setup.

Those that care about such should be open to understanding why the grade is marked as lower if you explain that it's a "bug" in the grading system, but then you may need to get more technical beyond their comfort, and they have trouble knowing if you're being honest or trying to hand-wave the lower grade.

If that's an issue, did they specifically request this? Does it really matter if they're unwilling to understand a report and blindly put faith in a tool that's had no commits since June 2020?

---

How is this still not resolved.

The project isn't maintained anymore, find an alternative, or educate whomever cares about that fact if they insist the score should be "A+".

EDIT: Sorry, it's been a while since I was last active in this thread. Looks like while this project / organization has no development activity, that maintainers are still active and engaging with users.

@naumanshah03 possibly gets too many notifications to respond to this or unsubscribed. If the ping doesn't work, opening a new issue may get a response.

Not sure if the linked comment is referencing an update to this project or the site, and how frequent those updates are, perhaps they've addressed the issue as part of an upcoming release if it's been a while?

---

FWIW, I maintain a mail server project and we still support TLS 1.2, enforcing TLS 1.3 only would be bad AFAIK.

Mail servers can lag behind a fair amount (I think it wasn't until 2014-2016 that TLS 1.2 support was more commonly available there), and even a few years after that I believe there was still some compatibility issues with macOS official mail client for TLS 1.2..

Not sure what the situation is currently, and that depends on which servers you need to interact with, big services should be fine, but sometimes it's dated clients.

I recall a scanner that tries to email the result wasn't compatible with TLS 1.2 due to age, yet someone was trying to use that this year, others EOL mobile devices from about a decade ago before they received TLS 1.2.