SSL & Early TLS vulnerabilities such as QID 38628 “SSL/TLS Server supports TLSv1.0”\ will be marked as a Fail for PCI as of May 1, 2017 in accordance with the PCI DSS v3.2. For existing implementations, merchants will be able to submit a PCI False Positive / Exception Request and provide proof of their Risk Mitigation & Migration Plan, which will result in a pass for PCI until June 30, 2018.
In the second half of 2016, a series of events unfolded that culminated with something many didn’t think was possible (or at least thought very unlikely): a public CA was distrusted. The CA in question was WoSign, a Chinese CA who made some waves by offering free certificates back in the day, before Let’s Encrypt came onto the scene. To make the case even more remarkable, another CA—StartCom—was distrusted at the same time. These were CAs with substantial installed user bases, largely because both had offered free certificates.
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. Per the earlier blog post, there will be other changes in 2017. We will talk in more detail about them later on.
Today saw another SSL Labs release, which brings several new features and includes one fix. In this blog post I will discuss what the new features are and why they’re interesting. As always, you’ll find the (recent) history of SSL Labs releases in the change log.
Even though SSL/TLS is criti
cal 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.
This change marks another milestone; for the first time, SSL Labs requires JavaScript for its full functionality. I know, it’s not really relevant, but still. For a really long time I liked the idea of providing a useful service without having to use any “bells and whistles”. But we move on!
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.