Qualys Blog

www.qualys.com
73 posts

Fixing HPKP with Certificate Constraints

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.

In my previous blog post I argued that the biggest flaw of HPKP is that it doesn’t tolerate failures. That’s why I offered pin revocation as a solution. In my approach, the CAs’ existing OCSP infrastructure is used for the revocation, keeping things simple. The main disadvantage of the proposal is that there is deep distrust of both CAs and also no faith that they will maintain rock-solid revocation infrastructure.

Rethinking the problems with HPKP, I decided that I could attempt to solve them from another angle. To summarise, there are two big problems with HPKP: 1) it’s too easy to activate by anyone who can set HTTP response headers on your site and 2) there is no way to recover from failure. This incredibly low activation bar allows deployments that haven’t been thought through, activation by mistake, and even malicious pinning. The lack of failure recovery makes it very dangerous.

Certificate Constraints

It recently occurred to me that we could fix things largely by allowing HPKP activation only on the certificates that allow it. Technically, this could be achieved by placing a special OID in the certificates when appropriate. If the OID is there, browsers pin, otherwise they don’t.

With this feature in place, CAs could designate certain intermediates as suitable for pinning, guarantee public key longevity, and place the appropriate OIDs in them. Because this is a special type of certificate, it’s not something that you’d get by default. And, even if you did, recovering from failure is as easy as getting a new certificate.

If we really wanted to—for the brave—we could use a different OID to allow pinning to the leaf, in which case HPKP would be more difficult to activate, as secure as it is today in preventing MITM attacks, but there wouldn’t be a way to recover from failure. In this case the CAs wouldn’t need to promise key longevity, but they would still operate as gatekeepers to make malicious pinning less likely. Honestly, I don’t think this OID is a good idea. Those rare companies that wish to pin can still fallback to static pinning (embedded in the browser code). Even though static pinning is inefficient, there’s so few of those who might be interested that it doesn’t really matter.

The most efficient and most secure way way to pin today is to get a pair of intermediate certificates from different CAs and pin to them. Obviously, only wealthy organisations can do that. With certificate constraints, nothing would change, as their intermediates would just need to have the correct OIDs in place.

Conclusion

Are there any drawbacks to HPKP with certificate constraints? You could argue that it makes pinning more expensive because it reduces the pool of CAs from which you can get your certificates. However, the certificate expense is only a fraction of the overall cost of pinning, so I think that the difference doesn’t really matter.

The best thing about this approach is that the browser vendors would only need to add a tiny amount of code to make it happen. Most of the work would be in standardising the OIDs.

Fixing HPKP with Pin Revocation

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 …

SSL Labs Grading Redesign (Preview 1)

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.

Continue reading …

PCI DSS v3.2 & Migrating from SSL and Early TLS v1.1

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.

Continue reading …

SSL Labs Distrusts WoSign and StartCom certificates

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.

Continue reading …

CAA Mandated by CA/Browser Forum

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.

Continue reading …

Ticketbleed Detection Added to SSL Labs

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.

Continue reading …

SSL Labs Grading Changes January 2017

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.

Continue reading …

What’s New SSL Labs 1.26.5 (13 Jan 2017)

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.

Continue reading …

SSL: Deceptively Simple, Yet Hard to Implement

An Interview with SSL Expert and SSL Labs Founder Ivan Ristić

Even though SSL/TLS is critiivan-risticcal 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.

Continue reading …