
What You Need to Know about HTTP Public Key Pinning (HPKP) - s4chin
http://blog.rlove.org/2015/01/public-key-pinning-hpkp.html
======
eps
In Firefox, is there a way to

1\. View pinned certificates/keys?

2\. Pin one manually, from the browser?

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'd expect I'm not the
only one who wants to pin few certs for sites that I visit frequently.

~~~
hobarrera
> I'd expect I'm not the only one who wants to pin few certs for sites that I
> visit frequently.

How can you tell what the backup pin for those websites would be without the
owner publishing the HKPK headers? How do you know the max-age of their
current pin?

It sound a bit like trying to stuff things into the browser's cache - a road
to disaster.

~~~
eps
I control these sites.

~~~
garrettr_
If you control the sites, just modify their server configuration so they send
the HPKP header.

If you don't control the sites, it is not a good idea to pin them "from the
browser" as you suggest.

------
ShakataGaNai
So now the flip side question. How would say a corporate SSL/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're allowed to roam on and off the proxy?

~~~
tshtf
Google Chrome allows TLS MITM proxies to override HPKP settings (which is not
without controversy):

 _We deem this acceptable because the proxy or MITM can only be effective if
the client machine has already been configured to trust the proxy’s issuing
certificate — that is, the client is already under the control of the person
who controls the proxy (e.g. the enterprise’s IT administrator). If the client
does not trust the private trust anchor, the proxy’s attempt to mediate the
connection will fail as it should._

[https://www.chromium.org/Home/chromium-security/security-
faq...](https://www.chromium.org/Home/chromium-security/security-faq#TOC-How-
does-key-pinning-interact-with-local-proxies-and-filters-)

[https://code.google.com/p/chromium/issues/detail?id=561646](https://code.google.com/p/chromium/issues/detail?id=561646)

~~~
pfg
Firefox defaults to the same implementation[1].

I'm personally fine with this. MITM proxies are a valid use case. I do think
that all parties should be made aware of it, but that's probably something
that has to be fixed via laws (I _think_ some European countries forbid this
practice unless it's been made clear that there can be no expectation of
privacy on a company-provided device).

[1]:
[https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn...](https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning#How_to_use_pinning)

------
mwpmaybe
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?

EDIT: Okay, the coffee is flowing and the gears are starting to turn. I guess
if I'm going to pin my cert, I should generate a new private key for the
backup, and if I'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?

~~~
jlgaddis
Yes. You want everything to be completely separate. In a way, It's kinda like
falling over to a failover machine -- different storage, different network
connection, etc.

If your "primary" certificate or any of the others in the chain is compromised
-- for whatever reason -- you want the ability to immediately switch over to
your "backup" certificate without problems or affecting your users.

------
sjtgraham
> 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's private
> key and your browser trusts their certificate, I can forge valid
> certificates for any website.

You don't have to compromise the root. This could still happen if a trusted
intermediate CA's private key is compromised, because that CA's certificate
was signed by the CA in the chain of trust that ultimately terminates with a
trusted root.

Also, how does rfc7469 work with respect to CRLs and OCSP?

------
snowwrestler
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.

Do I have that right?

~~~
sjtgraham
If you pin to a root CA you're vulnerable to MITM if an intermediate CA that
has the root in its chain of trust is compromised. Because that compromised CA
would be able to sign a cert for an arbitrary domain while still satisfying
your pinning directives.

By pinning to a public key you're saying "is this public key in this
certificate's chain of trust?". Pinning to a root you have the most
flexibility but the least amount of protection against MITM.

------
spangry
I'm not sure if this had been mitigated in the standard, but the pinning
implementations I've seen used in Android apps rely on client-side (i.e. app)
verification. It's an inconvenience, for sure, for someone trying to emulate
the app (in order to connect to the server API). But it's not sufficient to
stop a determined attacker with a bytecode decompiler.

For instance: [http://randywestergren.com/reverse-engineering-the-subway-
an...](http://randywestergren.com/reverse-engineering-the-subway-android-app/)

EDIT: Just to clarify given the comment below (and downvotes...), I'm talking
about a different attack scenario. Here's a decent source on some of pinning's
weaknesses for your standard MITM scenario:
[https://www.owasp.org/index.php/Certificate_and_Public_Key_P...](https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning#Pinning_Gaps)

~~~
pfg
I'm not sure I quite understand your point, but wouldn't an attacker with the
ability to modify an app on someone's device have access to the plaintext
anyway?

~~~
spangry
Oh sorry, I probably should have been a little clearer. I'm thinking of a
different attack scenario where the attacker wants to MITM your app to inspect
traffic and utilise your server-side API for unintended purposes. So it looks
like:

Attacker --> Attacker's Phone --> App --> MITM proxy --> API/Server

So you could use this to pull down real-estate listings from a real-estate app
in an easily parsed format (usually JSON). Or write an app that pull down the
odds from various sports betting app APIs, detects arbitrage opportunities and
automatically places bets using their APIs...

EDIT: Oh and on the plaintext thing, generally no. Most apps will use TLS for
app-to-server comms. Pinning in this context means they bundle the cert (or
signature) with their app. By the looks of this
([http://security.stackexchange.com/questions/29988/what-is-
ce...](http://security.stackexchange.com/questions/29988/what-is-certificate-
pinning)) it's a similar story with chrome: they pre-bundle some signatures.
The alternative is to pin on the first interaction, but this leaves you
potentially vulnerable if an attacker is listening in on that first
interaction. It also raises the question: what happens if the website needs to
revoke and re-issue? Wouldn't pre-bundling mean you'd have to wait for the
next browser update (and for out of band commms to have occurred between
google and the website)?

~~~
dingsbumps
I might be misunderstanding you, but I don't think Public Key Pinning is
intended to prevent this scenario at all. Public Key Pinning is a method for a
client to authenticate a server. If you decompile the app and recompile it
with the public key of your MITM server, the app would of course connect to
your MITM server. Or, it seems to me, if you have that level of control over
the client, you could just disable public key pinning checks completely.

