(No Ratings Yet)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

October 30, 2017 Comments closed

Google Deprecates Support for HTTP Public Key Pinning (HPKP)

in Everything Encryption

Once championed by Google, HPKP will soon be gone completely.

HTTP Public Key Pinning (HPKP) is a security standard that forces browsers to only accept certain “pinned” public keys when visiting a host for a given period of time. Google first introduced the feature back in 2015. But while it was well-intentioned, HPKP never really took off like anticipated.

On Friday, Chris Palmer wrote on Google’s Chromium blog that HPKP is dead.

Google will deprecate support for it next Spring, likely for the release of Chrome 67 in May. Chrome (and Opera) were the only major browsers that even fully support HPKP. Firefox never finished rolling out support and both Apple and Microsoft never even tried with their browsers.

A Palmer writes: “There is no compatibility risk; no website will stop working as a result of the removal of static or dynamic PKP.”

What went wrong with HPKP?

There was already quite a bit of chatter about why HPKP wasn’t worth setting up from industry luminaries like Scott Helme. In fact, our own Vincent Lynch even wrote an article about why HPKP is not an ideal choice.

Essentially it comes down to this. HPKP is kind of a clunky way to accomplish several things that are already being done better by other mechanisms and protocols.  Here’s how Palmer explains it:

PKP offers a way to defend against certificate misissuance, by providing a Web-exposed mechanism (HPKP) for sites to limit the set of certificate authorities (CAs) that can issue for their domain. However, this exposes as part of the Open Web Platform considerations that are external to it: specifically, the choice and selection of CAs is a product-level security decision made by browsers or by OS vendors, and the choice and use of sub-CAs, cross-signing, and other aspects of the PKI hierarchy are made independently by CAs.

As a consequence, site operators face difficulties selecting a reliable set of keys to pin to, and adoption of PKP has remained low. When site operators’ expectations don’t match the reality of trust anchors on real world client machines, users suffer. Unexpected or spurious pinning errors can result in error fatigue rather than user safety.

Concretely:

• It is hard to build a pin-set that is guaranteed to work, due to the variance in both user-agent trust stores and CA operations.

• There is a risk of rendering a site unusable.

• There is a risk of hostile pinning, should an attacker obtain a misissued certificate. While there are no confirmed or rumored cases of this having happened, the risk is present even for sites that don’t use PKP.

Pay specific attention to the three risks that Palmer brings up. It’s difficult to build the correct pin set. Lots of people, not understanding what they were actually doing, have made their sites unusable by actually building the wrong pin sets. And finally, there’s an attack vector that, while as of yet not exploited, could have disastrous ramifications.

Basically, it comes down to this, somebody with the requisite knowledge and background could make expert use of HPKP and it would work exactly as it was intended. Unfortunately, if you don’t know what you’re doing it’s possible to do more harm than good. And there are far more people on the web that fall into that second category than the first.

Then there’s the fact that HPKP could be exploited to do substantial harm if someone could obtain a mis-issued certificate. Generally, it’s not a good sign when a mechanism that’s designed to “defend against certificate mis-issuance” can actually be used to make certificate mis-issuance worse. Which it can hypothetically do in the form of “hostile pinning.”

In that scenario, hostile pinning could leave a website unusable. And HPKP was not designed with a recovery mechanism, which is, as SSL Labs’ Ivan Ristic states it, “problematic.”

Yes, I would say being “pinned” out of your own website would qualify as problematic.

As per what site operators should do in lieu of HPKP, Palmer writes:

“To defend against certificate misissuance, web developers should use the Expect-CT header, including its reporting function. Expect-CT is safer than HPKP due to the flexibility it gives site operators to recover from any configuration errors, and due to the built-in support offered by a number of CAs.”

• #Google
• #Google Chrome
• #HPKP
• #SSL/TLS