Update March 1, 2018: The completion of these changes is documented under Version 1.31.0 in the SSL Labs Changelog.
We are giving advance notification for following grading criteria changes applying from March 1, 2018: Not using forward secrecy, not using AEAD suites, and vulnerability to ROBOT. Update: This release also includes a grading change for some Symantec certificates.
Earlier this month, after roughly six months of deliberation and planning, Google finalised their plans for staged deprecation of Symantec certificates. The process began in March 2017 when Google had announced on the Blink mailing list that they had lost confidence about Symantec’s certificate issuance policies and practices of recent years. The initial deprecation proposal was very strict and looked like it would completely paralyse Symantec, ending with limiting their certificates to validity time of less than one year.
Over time, however, a different solution emerged and Symantec agreed to handle operations of their PKI to some other CA, selecting DigiCert for the role. In return, Google agreed to a deprecation plan that will still be difficult for Symantec, but allows them to resume issuance normally afterwards. Mozilla carried out their own investigation and decided to match Google’s actions and dates. In the final twist, Symantec decided to sell their certificate business to DigiCert.
This is the third post in my series on HPKP. In my first post I declared HPKP dead, and in my second post I explored the possibility of fixing it by introducing pin revocation. Today I will consider an entirely different approach to make HPKP much safer, by changing how it’s activated.
Last year, almost exactly to the day, I declared HPKP effectively dead. I believed then—and I still do—that HPKP is too complex and too dangerous to be worth the effort. The biggest problem lies in the fact that there is no sufficient margin of safety; pinning failures are always catastrophic. That’s always bothered me and I wondered if it was possible to somehow fix HPKP without starting from scratch. That’s what this blog post is about.
If you haven’t already read my last year’s blog post, I suggest that you do so now as it will make the discussion easier to follow. I’ll wait for you patiently until you come back.
Today I am exploring the possibility of fixing HPKP with an introduction of pin revocation, which would be used in case of emergency. Please note that, even though I’ll be trying to save HPKP from a technical perspective, I am not necessarily declaring that HPKP is worth saving. The landscape of PKI had changed and today we have Certificate Transparency (CT), which addresses one set of problems that HPKP was supposed to solve, and also Certification Authority Authorization (CAA), which addresses another set of problems. One could argue that, between CT and CAA, there is perhaps not enough left for HPKP to do, given its complexities. I’ll leave that discussion for some other time. For now, let’s attempt the challenge of making HPKP more palatable. Continue reading …
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.
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.