What You Need to Know about HTTP Public Key Pinning (HPKP)

In Firefox, is there a way to<p>1. View pinned certificates&#x2F;keys?<p>2. Pin one manually, from the browser?<p>From what I understand neither is possible, even though this was added to Firefox 1.5 years ago. Which really makes you go Hmm. I&#x27;d expect I&#x27;m not the only one who wants to pin few certs for sites that I visit frequently.

So now the flip side question. How would say a corporate SSL&#x2F;TLS proxy, which is effectively a MITM, bypass this security feature? I can see the TOFU is easy to defeat by dropping the header before it gets to the client, but what if they&#x27;re allowed to roam on and off the proxy?

I feel stupid having to ask this question, but is a backup key literally just a different SSL certificate issued by the same or another CA for the same domain(s)? You keep it on standby in case your primary certificate is compromised? Do I use the same CSR and private key or do I generate new ones?<p>EDIT: Okay, the coffee is flowing and the gears are starting to turn. I guess if I&#x27;m going to pin my cert, I should generate a new private key for the backup, and if I&#x27;m going to pin the intermediate cert, I should use a different CA. And for maximum protection, do both, and not keep both private keys on the same servers. Does that make sense?

&gt; A flaw in this system is that any compromised root certificate can in turn subvert the entire identity model. If I steal the Crap Authority&#x27;s private key and your browser trusts their certificate, I can forge valid certificates for any website.<p>You don&#x27;t have to compromise the root. This could still happen if a trusted intermediate CA&#x27;s private key is compromised, because that CA&#x27;s certificate was signed by the CA in the chain of trust that ultimately terminates with a trusted root.<p>Also, how does rfc7469 work with respect to CRLs and OCSP?

This article suggests pinning ones own cert, and perhaps an intermediate up the chain. It seems that even pinning one root cert would be an improvement, because then that specific CA would have to compromised to MITM. As opposed to the situation now, in which compromising any trusted CA can permit MITM.<p>Do I have that right?

I&#x27;m not sure if this had been mitigated in the standard, but the pinning implementations I&#x27;ve seen used in Android apps rely on client-side (i.e. app) verification. It&#x27;s an inconvenience, for sure, for someone trying to emulate the app (in order to connect to the server API). But it&#x27;s not sufficient to stop a determined attacker with a bytecode decompiler.<p>For instance: <a href="http:&#x2F;&#x2F;randywestergren.com&#x2F;reverse-engineering-the-subway-android-app&#x2F;" rel="nofollow">http:&#x2F;&#x2F;randywestergren.com&#x2F;reverse-engineering-the-subway-an...</a><p>EDIT: Just to clarify given the comment below (and downvotes...), I&#x27;m talking about a different attack scenario. Here&#x27;s a decent source on some of pinning&#x27;s weaknesses for your standard MITM scenario: <a href="https:&#x2F;&#x2F;www.owasp.org&#x2F;index.php&#x2F;Certificate_and_Public_Key_Pinning#Pinning_Gaps" rel="nofollow">https:&#x2F;&#x2F;www.owasp.org&#x2F;index.php&#x2F;Certificate_and_Public_Key_P...</a>