(2 votes, average: 3.00 out of 5)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

August 28, 2017 Comments closed

Industry Experts Agree: Don’t Use Key Pinning (HPKP)

in Industry Lowdown

Can A Security Mechanism Be Too Powerful?

Since its inception, HTTP Public Key Pinning (or HPKP) has been one of the most controversial features of HTTPS. It was designed to defend against one of the most serious threats facing HTTPS – but it also gave site operators an incredibly powerful tool to accidentally self-inflict damage.

Last week the debate over HPKP was re-started and a number of leading HTTPS/TLS experts publicly voiced their opinion that the vast majority of websites should not use HPKP. Some even claimed the mechanism was doing more harm than good.

So, why did the industry turn against HPKP, and what harm is it causing?

The Promise of Pinning

At one point, pinning showed great promise. Google was pinning their certificates as early as 2011, before it had become an IETF standard, allowing them to detect the breach of the CA DigiNotar.

The CA had been entirely compromised – attackers had gained access to their network and were able to issue certificates for any website they wanted to. This is one of the most serious threats to the security of the Web PKI system, and HPKP’s role in detecting this attack suggested the mechanism could greatly benefit users.

HPKP works by allowing a website to tell browsers that it should only accept certificates using specified encryption keys. This is done with an HTTP header the browser remembers (or “pins”) for a configured time period. For that period – usually a few months – the browser will enforce those instructions and refuse to connect if a certificate using any other key is presented, even if it is issued by a trusted CA (after the period the browser checks for fresh HPKP settings).

Browsers present an un-bypassable error if the certificate provided contains a non-pinned key. This completely removes the user’s ability to make a connection where they could be a risk of a man-in-the-middle attack or use of an unauthorized certificate. It also acts as a DoS if you happen to deploy HPKP incorrectly.

Using HPKP is not as easy as flipping a setting from off to on. There are a number of decisions to make: which part of the certificate chain do you pin (leaf, intermediate, root)? How many backup keys should you pin? Do you need to pin certificates from multiple CAs in case one is un-trusted or incompatible?

These choices are one reason that HPKP can be dangerous. There are a range of combinations that balance security and flexibility. For instance, pin to your own leaf keys and you can entirely eliminate the risk of mis-issuance. But now you risked the availability of your website against a few public keys that you must guard with your life and hope don’t become outdated.

Even if you follow best practices, there are still factors out of your control. The CA you have pinned to could unexpectedly change the path they issued from, making it difficult or impossible to get a replacement certificate when your current cert expires. The keys you have pinned could become weak (such as when the industry moved from 1024- to 2048-bit keys, a risk which technically can be accounted for, but requires even more expertise).

Self-inflicted HPKP pain is not just a conceptual threat. Smashing Magazine was inaccessible for four days when they renewed their certificate using a new key which had not been pinned. Luckily their web host had retained a copy of their old private key, allowing them to issue a new certificate from it and fix the error. Things would have been much worse for them if that key had been deleted or lost.

Problematic Pinning

The ability to misconfigure or otherwise screw-up HPKP has always been known-risk and concern. Browsers accounted for this risk by objecting risky configurations. For example, if you do not provide a backup pin, or set an excessively long max-age (the time period for obeying the settings), the browser would not enforce the HPKP settings to avoid common screw-ups.

But now many industry experts, including authors of the RFC, are pointing to other risks in using the mechanism and say HPKP is a mistake.

The problem is not that HPKP can’t provide security value. In the DigiNotar attack, it prevented attackers from MITM-ing Gmail connections – which would have been disastrous if it had been successful. The problem is that HPKP locks websites in and constricts the Web PKI.

Ryan Sleevi, one of Google’s engineers working on TLS, and one of the authors of the HPKP RFC, stressed the bigger picture issues with HPKP. “The choice to pin doesn’t just affect one [website], but the whole ecosystem,” Sleevi said, referencing the challenge of dis-trusting CAs due to websites that have pinned their certs and rely on them being accepted by browser.

Sleevi went as far to write that HPKP “harms the ecosystem more than helps,” and that he “actively discourages it now.”  Chris Palmer, another co-author of the HPKP RFC, also said that making it an internet standard was a mistake.

In reality, the threats that HPKP defends against – CA compromise and unauthorized issuance – are not applicable to the majority of the internet. Widely deploying trusted certs from a compromised CA would lead to quick detection of the breach, and only the world’s most popular sites would warrant the effort required for a targeted attack.

This means that the number of sites that should use HPKP number in the hundreds – but making it an IETF standard has made it accessible to millions. While no one is putting a gun to a web admin’s head and shouting “pin those keys, dammit!” there is a desire to avoid giving users the ability to make such mistakes.

Scott Helme, a researcher who frequently covers TLS topics, started this new denouncement of HPKP with his article, I’m Giving Up on HPKP.

In total agreement with @Scott_Helme here, HPKP is almost certainly not something you want: “I’m giving up on HPKP”: https://t.co/T23HOgXLQC

— Troy Hunt (@troyhunt) August 24, 2017

//platform.twitter.com/widgets.js

In that post, he describes some other risks of HPKP – such as the ability of an attacker to purposefully deploy HPKP as a way to DoS your website. Helme pointed out that other mechanisms – such as Certificate Transparency – can provide similar benefits without the risk.

Ivan Ristic, the creator of SSL Labs, was one of the first industry leaders to express concern over HPKP. In 2016, Ristic wrote, “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.” He continued on, expressing the same fear that “it’s too difficult and too dangerous to use.”

I agree with what Helme, Ristic, Sleevi, Palmer, and Hunt have said. HPKP is too complicated, risky, and quite frankly, unnecessary for the internet-at-large.

• #HPKP
• #ryan sleevi
• #SSL Certificates
• #SSL/TLS