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.
We are releasing an update to the grading criteria, version 2009m, to respond to the discovery of the OpenSSL vulnerability CVE-2016-2107 announced in the OpenSSL Security Advisory [3rd May 2016]. This vulnerability can be exploited by MITM attacker using a padding Oracle attack to decrypt traffic when the connection uses an AES CBC cipher and the server supports AES-NI.
We are releasing an update to the grading criteria, version 2009l, to respond to the discovery of the DROWN attack. If a server is found to be vulnerable to DROWN it will be given an F, even though it might not support SSL v2 itself. (The nature of the DROWN vulnerability is such that servers that support SSL v2 can affect other servers, irrespective of supported protocol versions). You’ll find more information about our DROWN test here. Additionally, servers that support SSL v2 but don’t have any cipher suites configured are treated as if they had SSL v2 fully enabled.
This update also contains two fixes to our grading code, which we don’t consider to be changes to our grading criteria:
- Servers that have invalid HPKP information are not awarded A+.
- Servers that have an RSA key with exponent 1 are given an F.
Two days ago the DROWN vulnerability came to light, showing new ways to attack TLS. SSL Labs deployed tests for DROWN in the staging environment yesterday, and we’ll be pushing it to production shortly. Because DROWN is a tricky problem, the aim of this blog post is to provide an explanation of what we test for and how exactly.
A fascinating new research called DROWN has uncovered a previously-unknown vulnerability in SSL v2, the first ever version of SSL that was released in 1995 and declared dead less than a year later. Even though this old version of SSL is not used much these days, it continues to be supported by many servers. The especially bad aspect of this attack is that it can be used to exploit TLS, even in cases when client devices don’t support SSL v2, and sometimes even in cases when the servers don’t support SSL v2 (but use the same RSA key as some other server that does). The researchers estimate that up to 22% of servers could be impacted by this problem.