HTTP Public Key Pinning Usage is Essentially Zero

A slow start for the new security standard

Posted by Stefán Orri Stefánsson on 12 May 2015

HTTP Public Key Pinning (HPKP) is a brand new standard for a new HTTP header from IETF. It’s an instrument for websites to tell browsers which SSL/TLS certificates they should accept, or limit the accepted certificates to those issued by specific certificate authorities (CAs). The purpose is to prevent against man-in-the-middle attacks due to compromised or misbehaving CAs. For more details Mozilla has an excellent write-up with configuration examples. Although the standard was published last month, it has been supported by Chrome and Firefox for several months now.

Minimal usage

Despite the obvious benefits of HPKP, websites aren’t exactly rushing to implement it. It doesn’t show up on the HTTP Security Report site survey for the top 500 sites on the web.

In fact, only two of the Alexa top 5000 sites send the public-key pinning header, Yts.to and Python.org. In fact, Yts.to gets it wrong because it only includes one key pin and browsers therefore must ignore it. The standard requires at least two pins, with one used as a backup pin in the event of a key compromise. Because of the faulty header, Chrome silently ignores it but Firefox shows an error in the developer console.

Yts.to uses the HPKP header, but it has an invalid value</a>.

That leaves us with a single site correctly implementing HPKP, making the usage rate 0.02%. However, they appear to be treading carefully - the pins are only set for 10 minutes, making them pretty useless. This is a perfectly normal way to start out since the consequences of an incorrect implementation are serious. In the worst case, users could be locked out from the site for a prolonged time. Expect Python.org’s pinning duration to rise if no major problems occur.

Why aren’t more sites using HPKP?

Before HPKP, many major sites had their public keys “preloaded” into Chrome and Firefox, yielding the same protections. Those sites are still included in the preload lists. The preload lists won’t go away, but the sites are expected to also implement the HPKP header in the future. That’s the case for HTTP Strict Transport Security, which is currently used by 17% of HTTPS sites and slowly gaining traction.

A handful of preloaded sites doesn’t fully explain the limited usage. Nor does limited browser support - Chrome and Firefox own more than half the market. Right now one of the biggest reasons seems to be low awareness of public key pinning. It will be interesting to see whether the numbers will start to creep up now that the standard has been finalized.

Update June 2015

Github is now using HPKP, the first of (hopefully) many top-100 sites to do so. Great work, you are awesome!


Photo credit: 'Eyrarbakki Aurora Panorama', Iceland. Photo by Kris Williams. Licensed by CC BY-NC-ND 2.0.