Certification Authority Authorization (CAA), specified in RFC 6844 in 2013, is a proposal to improve the strength of the PKI ecosystem with a new control to restrict which CAs can issue certificates for a particular domain name. Although CAA had been in the proposed-standard state for more than 4 years, there was little obvious happening until very recently, with only a hundred or two hundred sites adopting it. But that’s going to change, because the CA/Browser Forum recently voted to mandate CAA support as part of its certificate issuance standard Baseline Requirements. The changes will become effective in September 2017.
Ticketbleed is a recently disclosed vulnerability in some F5 load balancers. This problems allows attackers to retrieve up to 31 bytes of process memory, which could potentially include sensitive data (for example private keys). It is similar in nature to Heartbleed (a vulnerability in OpenSSL from 2014), but less severe because much less data can be extracted.
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.
An Interview with SSL Expert and SSL Labs Founder Ivan Ristić
Even though SSL/TLS is critical for the privacy, integrity, and security of internet communications, the protocol is implemented in an optimal way in only a small percentage of web servers, meaning that most websites and web apps aren’t as secure as they could be.
It doesn’t have to be that way, which is why Ivan Ristić, a security researcher, engineer, and author known for his expertise on various aspects of InfoSec, has spent years contributing to the field of SSL/TLS.
He launched SSLLabs.com in 2009 to provide SSL/TLS tools, research and documentation, brought it with him when he joined Qualys in 2010, and ran it until mid-2016, when he became an advisor. Under his leadership, SSLLabs.com became a de-facto standard for secure server assessment and the go-to site for organizations looking for help improving their SSL/TLS configurations.
Ristić also wrote an entire book about the topic titled “Bulletproof SSL and TLS: Understanding and Deploying SSL/TLS and PKI to Secure Servers and Web Applications.” We recently had a chance to catch up with Ivan and pick his brain about SSL/TLS challenges, best practices and trends. Here’s what he told us.
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.