SSL Labs Grading Redesign (Preview 1)
Last updated on: October 21, 2021
We’re excited to share with you the first preview of our next-generation grading. This is something that’s long overdue but, due to lack of available time, we managed to keep up patching the first-generation grading to keep up with the times. Now, finally, we’re taking the next necessary steps to modernise how we grade servers based on our assessments.
Grading Redesign Goals
Before I show you the new version of the grading, I’d like to explain what we’re set out to achieve:
- Cleanup. SSL Labs grading was initially designed around numerical scores in various categories. That approached worked for a period of time, back in the day when most cryptographic elements appeared to be relatively secure. This system is still employed at the core, but it’s now largely obsolete and complicates the work.
- Simplification and assessment decoupling. Our new goal is make it easier to understand how grading is done and, perhaps more importantly, enable others to replicate our results. In other words, we wish to decouple the grading logic from our assessment implementation.
- Meaningful grades. Although the A-F grading we have in place works great, we’re not making full use of the entire grade range. Additionally, the grades don’t have defined meanings, making it more difficult to keep the grading approach consistent over a period of time.
- Even better security. Finally, we wish the next major update to further push security forward by requiring better security. This is something we’ve been doing regularly over the years, and this time is not going to be an exception.
Preview 1 Reveal
Without further ado, we’re releasing a Preview:
The focus on this release is on the grading algorithm concept (i.e., the way how rules are defined, specified, and processed). Although the rules themselves resemble what will actually be the next-generation criteria, they haven’t been fully tuned. In fact, our next step will be to specify the grading storage formats and build a proof-of-concept tool to compare the current grades and the future version. We intend to use this tool to refine the grades over the following months.
If it’s the criteria only that you’re interested in, please refer to my earlier blog post on this topic.
I notice SSL Labs no longer highlights ChaCha20 suites when preferred on non-AESNI-accelerated platforms.
Is this a bug, or is that behavior not really used by clients anymore?
Can you share a link to a site where you expect a highlight for ChaCha20? AFAIK, SSL Labs didn’t make any changes in this area. Also, I’ve noticed recently that some of the site operators prefer ChaCha20 in a way that makes it difficult to test. That’s because they make their decisions based on a few known devices, not in a general sense (i.e., based on the order of offered cipher suites and so on).
Sorry for the late reply. Sites that I had seen highlighted ChaCha20 have been most Google domains and any website proxies through Cloudflare. Both those services have been configured to prefer ChaCha20 suites on systems that do not have a CPU with AES-NI acceleration.
I don’t think anything has changed on the SSL Labs side. Having spent some time recently at how Cloudflare select their suites, I think it’s more likely that they had changed their selection logic into something where ChaCha20 preference can’t be detected in a straightforward fashion.
Sorry for the late reply, but here are my findings on 8/19/17:
I just tested a Cloudflare Enterprise customer (I assume they are Enterprise because they use custom nameservers) and the ChaCha20 highliting works. They happen to have TLS 1.3 Draft 18 disabled.
I tested what used to be a free customer (now turns out they are Business or Enterprise due to the certificate only holding the Cloudflare SSL and one domain). They have TLS 1.3 Draft 18 enabled, and the highlighting is not working.
Perhaps there is a conflict between the TLS 1.3 Draft 18 scanner and the detection of ChaCha20 preference on TLS 1.2?
I don’t want to pollute the document with my comment, because it is little bit more radical. I have to tell you, I don’t like the current T grade at all. Isn’t there always a trust issue. You have to have trust in strong cipher suites, you have to have trust in many other things, also certificate. But why add additional confusion with T grade for special cases like certificate trust. In many cases there should in my humble opinion just be F grade. Like certificate name mismatch – the most likely cause? Badly configured server (it deserves F grade) or MiTM attack (it also deserves F grade).
Currently in document all of bellow (in next paragraph of my comment) get an T grade. But I think T grade should be omitted as much as possible. Don’t really understand the point of T grade if it is not some how big reason to have it. There was a discussion on forum few years back (and several times repeated over years) and there was a suggestion that T grade was invented for sites that are using there own CA root certificate not included in browser. I have seen some government sites that are using its own CA root. This kind of sites are perfectly secure if user manually imports CA root certificate and UNDERSTANDS what he/she is doing. For this purpose only I would mark a site with T grade. So this kind of grading would mean T grade can be perfect A+ site if user TRUSTS the certificate and knows what he/she is doing, but can also have F grade if there is MiTM attack. In this case T grade is not absolutely bad grad, T grade just means grade can’t be fairly assigned without knowledge why site is using root certificate that is not included in browser certificate store.
For all other purposes it is in my humble opinion clear the site has bad security practice and why should we say SSLv3 is bad thing that deserves F grade, but certificate name mismatch is just a trust problem. In my humble opinion both sites deserves F grade.
For all other purposes (except non-root CA) I would assign non-T standard grade:
Certificate signature algorithm obsolete –> this is insecure and should probably get F grade
Certificate has no SAN information –> incorrectly issued certificate get F grade
Certificate not yet valid or expired –> security issue, grade F
Certificate name mismatch –> can be MiTM, so grade F
Certificate chain not trusted (not leaf issue) –> what does this mean like intermediate certificate has expired? then F
Certificate chain could not be validated –> if I understand correctly this is the root CA not included in default browser certificate store – in this case only I would apply T grade.
Hi, I noticed some sites redirect HTTPS to HTTP, and currently still get a A grade. There should also be a rule to penalize that practice to F/T.
Thanks.