HTTP Public Key Pinning: No Longer a Good Idea

Public Key Pinning was great idea at first. Google used static public keys to protect their websites. In doing so, the keys were embedded in Chrome and were useful in helping users find the DigiNotar attack in 2011, and in a mistaken certification authority (CA) certificate issued by TURKTRUST in 2012.

Rolling out static HTTP Public Key Pinning, or HPKP in this manner, was not scalable, but Adam Langley of Google made this offer:

“If you run a large, high security site and want Chrome to include pins, let me know. For everyone else we hope to expose pinning via HSTS, although the details have yet to be worked out. You can experiment with pinning via the HSTS debug UI (chrome://net-internals/#hsts) if you have a new enough version of Chrome.”

RFC 7469 introduced by IETF allowed website administrators to provide a server header with one or more public keys creating a memorable cryptographic identity that prevented man-in-the-middle attacks. This HTTP header brought dynamic HPKP to the masses. The header would be stored for a period of time by the browser and displayed an error if the key did not match. In fact, a site could be blocked for that user if there was a public key change.

So what public key should the website administrator use for HPKP?

The problem with public keys is that further down the chain there is a greater likelihood that the key will change. Higher up the chain there is an increased chance that trust will be spread where it should not be.

  • Server Public Key –

    The server pubic key should change when an SSL/TLS certificate is renewed. This goes for scheduled renewals as well as forced renewals. Events that trigger a forced renewal include the policy change to move from SHA-1 to SHA-256 signed certificates or in the event of a vulnerability. For example, the Heartbleed attack that occurred during the period of development of HPKP requiring the server public key to change. Don’t forget, you can also lose the key or it could be compromised in which cases you would also need to change it.

  • Issuing CA Public Key –

    The issuing CA public key is controlled by the CA. Some scenarios to be aware of is that the CA might have more than one issuing CA or the issuing CA’s public key could change. It might be best to use this key as long as the administrator is in contact with the CA, and can add in multiple public keys to help anticipate any changes.

  • Root CA Public Key –
    There was a time when I would have considered the root public key as the way to go. The administrator chooses a CA who will trust their root, but one issue is a root might cross-certify third party issuing CAs that are not trusted. There have also been several instances when roots have lost browser trust such as CNNIC, WoSign, StartSSL and soon many roots from the Symantec portfolio of products.

In summary, it is very difficult to select a public key or a set of public keys that can be trusted for a long period of time. If the wrong public key is used, a website can be bricked until the server header expires. The wrong key could be provided accidentally or by an attacker. As in many cases, a site can be bricked where the administrator knows nothing about HPKP, or it’s been redirected by an attack.

Other industry experts have also given up on HPKP:

  • Ivan Ristić: Is HTTP Public Key Pinning Dead? “I think that, ultimately, HPKP requires too much effort and that only a small number of sites will ever deploy it. At the same time, it can be—in the current form—used as a powerful weapon against everybody. The irony of HPKP is that it’s not going to be used by many sites (because it’s too taxing), but that it can be used against the long tail of millions of small sites who are not even aware that HPKP exists. For the small number of sites who are using pinning, it’s just as likely that static pinning would work well, with less fuss and no danger for the rest of the Web.”
  • Scott Helme: I’m giving up on HPKP  “The problem with HPKP is that it can be quite a complex idea to get your head around and requires a perfect deployment otherwise things can go wrong.”
  • The SSL Store: Industry Experts Agree: Don’t Use Key Pinning (HPKP) “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.”
  • Ryan Sleevi (RFC 7469 co-author): “But pinning is terrible – and harms the ecosystem more than helps, as we’ve seen. It was a bad thing to standardize.”

Deployment of HPKP is not recommended. Instead it is recommended organizations use Certification Authority Authorization (CAA) to prevent attacks and website monitory using the Certificate Transparency (CT) logs. Both CAA and CT are relatively risk free.

*** This is a Security Bloggers Network syndicated blog from Entrust Datacard Blog authored by Entrust Datacard Blog. Read the original post at: