About two months ago we announced that we will be making many grading changes in 2017. In this email we will highlight only the first batch of changes, but most of all we want to introduce a new feature that will help our users stay informed as we continue to evolve our grading system; it’s our grade-change notification system.
Just a couple of days ago SSL Labs started showing multiple certificates when they are configured for the same host, and we now have another useful feature lined up—per protocol cipher suite testing. When I started working on SSL Labs in 2009, everyone had the same cipher suite configuration, no matter what protocol version was used. In the years that followed we had various security issues in earlier protocol versions, and the ability to configure per-protocol cipher suites slowly started to find its way into libraries. Today, different suites for different protocols is still not very common, but not rare any more.
When we designed the SSL Labs report originally, we allowed room for only one certificate per server. Even though it was technically possible to support multiple certificates for a single host, only a small number of web servers supported it and nobody was actually doing it. Why would they… RSA worked well and cryptography wasn’t as important as it is today.
But, over the years, people started deploying RSA and ECDSA certificates in parallel. These days, many web servers support this option and it’s not at all uncommon to find such web sites. Now, SSL Labs has always been collecting all observed certificates, but they were not shown in the report. When we started to work on the v3 API, we made changes to expose all the certificates. Now, finally (as of 1.25.2), they appear in the main report as well.
To accommodate the additional certificates we made to make some changes to the page design. SSL Labs report was very long even before this change and adding more certificates would mean much more data. So, in an attempt to show less, we’ve taken a decision to hide certificate trust paths by default. We think this is information that most people won’t look for anyway, and those who do can still find it.
At SSL Labs, we have a major review of our grading criteria about once a year. As the security of the ecosystem matures, our goal is to push forward and make the requirements [for a good grade] stricter. In many ways, this process of continuous improvement is what really matters to us.
According to our measurement in SSL Pulse, over 40% of the monitored sites have configuration that can be considered good. However, only about 3% of those get an A+, which is what everyone should be aiming for. So our goal with the design of the grading criteria is to push the number of A+ sites up.
In this blog post we will announce our short-term changes as well as outline some further changes that we will be making in 2017 and beyond. From the list below, the 3DES grading change will happen first. Other changes will follow. The main purpose of this blog post is to outline our grading directions so that organisations can start to plan their improvements.
I have a confession to make: I fear that HTTP Public Key Pinning (HPKP, RFC 7469)—a standard that was intended to bring public key pinning to the masses—might be dead. As a proponent of a fully encrypted and secure Internet I have every desire for HPKP to succeed, but I worry that it’s too difficult and too dangerous to use, and that it won’t go anywhere unless we fix it.
In one of the future SSL Labs releases we will change how we detect supported protocol suites. Even though there will be no change to the grading algorithm because of this, our detection of obsolete and insecure suites will improve slightly, and that will worsen the grade of a small number of sites. We will publish this new version on October 1st or later.
You often hear that TLS is the most important security protocol. Usually, the reasoning is that it’s very widely deployed and also that it works for many higher-level protocols. That’s certainly true, but for those who work more closely with these protocols there is another important aspect: we can learn so much about protocol design by carefully examining the evolution of TLS.
This month I released an updated version of SSL/TLS Deployment Best practices—my favourite SSL Labs publication—bringing the document up to date again. Given that the previous release was a long time ago (December 2014!), this version has quite a few changes and improvements.
In early 2009, SSL Labs was just this idea I had, born out of frustration with having to deal with a very complex subject without good documentation and tools. I wanted something that worked for me, and didn’t really anticipate that it could become as popular as it is today. The first version launched in the summer of that same year.