The use of certificate (or public key) pinning can be considered as a good practice for defense in depth, since it protects an application from man in the middle and DNS hijacking attacks. But can it be considered a flaw in the application itself?

Let’s take from example a case where a self signed certificate is either installed in the mobile phone or is signed by a trusted CA (using Let’s Encrypt), and an application that uses the phone trust store to determine whether a certificate is trusted. In any of these cases, an application without pinning would be exposed to MITM attacks; however, in order to do so, either a malicious application (or even the user, by social engineering) must install these certificates. In both cases, if said applications can accomplish this, they can go much further and take over the phone entirely.

  • One side of the discussion is developed in this video: youtu.be/PNuAzR_ZCbo – korrigan Mar 14 '18 at 8:38
  • 1
    The lack of a defensive measure is not necessarily a vulnerability. – forest Mar 15 '18 at 4:16

The use of certificate (or public key) pinning can be considered as a good practice for defense in depth

HPKP can be considered good only when it is carefully designed and implemented. In theory, public key pinning is more secure because it reduces surface attack by limiting a number of certificates (trust anchors) the application trusts. Biggest issue with public key pinning is certificate management. This is where most HPKP stories end.

If you trust only particular certificate/public key, it is irrevocable. If key is compromised, the application becomes immediately vulnerable, because you it is hardcoded in the application. The same story is when you simply replace the certificate. You will have to update the application, upload to app store and wait until clients update the app on their devices. Security is always a tradeoff between security and flexibility.

Better solution would be to ship a set of trusted anchors (trusted root certificates) your application trusts and configure certificate validation logic (built-in in OS, do not roll your own crypto) to use only these roots as trusted anchors. That is, chains still must be validated, revocation checking must be performed even if you use HPKP. This approach assumes that CA key compromise is less likely than SSL server key compromise. In this case, you have better security and flexibility. However, you still have maintain the list of trusted anchors and update them when necessary (because you no longer rely on system trust store).

Again, it is in theory. In practice, most app developers don't care at all and their HPKP implementation is worse (more vulnerable) than standard system trust store.

Worth reading on HPKP: https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-key-pinning-dead.

  • This isn't entirely correct. The HPKP standard requires you use more than a single public key. You could try to cheat the system by making the normal and backup key the same, but then you're really just screwing over yourself. – forest Mar 15 '18 at 4:03
  • This requires the logic that when backup key is used, main key must be banned on client, because if backup is used, main key is compromised. And the logic complicates when you have more than one backup keys. – Crypt32 Mar 15 '18 at 6:24
  • Once you switch to your backup key, you can issue a new HPKP policy. Additionally you can revoke the previous key. This is all described in the RFC. – forest Mar 15 '18 at 6:26

I wouldn't use HPKP for anything, especially if the team is using self-signed certs, HPKP should never be considered an option.

HPKP helps address nation-state attackers, who might be able to own a cert authority, and get their own cert. Otherwise, good ol' HSTS should suffice, because very few attackers have the capability to get any valid cert for a domain they don't control.

The one real DRAWBACK of HPKP, is it can cause serious(!) issues. If you host a website on a server with HPKP, and the server blows up,or you lose your keys -- this is catastrophic.

This has happened to SmashingMagazine, which they cover in this blogpost. In short, they summarize it better than I can:

Key pinning protects against a relatively rare attack that’s very hard to pull off and that’s not a major threat scenario against a content-driven website like Smashing Magazine, but it does so at the cost of potentially causing major — in the worst case even catastrophic — outages

HPKP suicide is bad, but worse still is HPKP Ransom. When an attacker hacks your site, swaps the keys, and sets HPKP, only to come back and delete that key a while later. Visitors who've come to your site while HPKP was set, are now going to have to jump through massive hoops to visit you again.

And that's why Google will stop supporting HPKP in chrome this May: https://www.theregister.co.uk/2017/10/30/google_hpkp/

In short, if your team is still using self-signed cert --- you definitely are not sophisticated enough for HPKP.

  • This answer is terribly misinformed. The backup key is designed to avoid both of these issues (i.e. it's not kept on the same server). Not to mention, if someone hacks your site, they can just enable HPKP with a non-existing key regardless of whether or not you are using it! Anyone who is having these problems is not deploying HPKP correctly. – forest Mar 15 '18 at 4:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.