Ask HN: Thoughts on an alternative to Public Key Pinning (HPKP)? | Hacker News Reader

Ask HN: Thoughts on an alternative to Public Key Pinning (HPKP)?

5 pointsjacobn2 comments

Public Key Pinning (HPKP) is a great concept - announce to the world that this is the one true certificate, and no MITM who is able to create a valid certificate can intercept traffic from browsers that have been made aware (inoculated).

Great! Except when you need to change your certificate of course.

They've added some workarounds whereby you can specify both a time duration and an alternate certificate, but as a small website operator, I need (want) to be able to make changes at any time, and I don't have my next certificate yet.

So what I really want is not to lock down a specific certificate, but make it so that I am the only one who can issue valid certificates for my site.

To achieve this, instead of pinning a specific public key, why not allow me to specify a self-signed root certificate with which I promise to also sign any HTTPS certificate?

I.e. any certificate presented for my site will be signed by a regular CA just as normal, but in addition to this, it will also be signed by my own home-brew certificate, as specified in a HPKP2 header.

This way, I can change my certificate any time, and Evil People will have to not only subvert a CA, they also have to get my private key, which I can keep as safe as I care / am able to.

This would be no more secure than current HPKP since it's still "trust on first visit", but should be easier for websites to deploy & maintain.

Thoughts?

(There were some threads recently on the abysmal uptake of HPKP among the top 1M sites, and it made me think of why I haven't implemented it on mine)

Not sure you will see this as your question is a couple days old now, but it is possible to create one or more backup keys & CSRs to use to generate a second hash. When you say "I don't have my next certificate yet" you should know that you don't need it, that's perfectly fine.

You would include the fingerprint of the second CSR along with the fingerprint of your current certificate in the header, and then if you ever need to change certs you generate a new one from that same second key & CSR.

Scott Helme's blog post here walks you through the steps and provides examples: https://scotthelme.co.uk/hpkp-http-public-key-pinning/

Hope that helps!

Pinning necessarily has to restrict the times a certificate can be changed because otherwise we have to solve a different problem "How can I tell this new certificate is a good certificate".

You have proposed a solution to that second problem, let's look at the threat model:

You adversary is:

* Capable of forcing or otherwise being able to create valid certificates.

* Has the capability to MITM nodes in a network.

The solution you have provided adds an additional hurdle for the adversary:

* must also be able to subvert your CA (or more generally, a specific CA - it doesn't actually matter if you or someone else controls it - what matters is it is a specific root certificate).

So the browser, now TOFU'ing the initial certificate makes a note of the current certificate (and pins it) as well as the secondary signing CA (and also pins that).

When you want to rotate certificates you have your new cert signed by the two CA's, one of which has to be the pinned CA.

I actually think this is a fairly elegant solution (for the operator), although it does come with some fairly large assumptions:

* If your adversary is large enough to be able to corrupt multiple CA's (say a federal government) - then they are powerful enough to corrupt all your CA's (even you - although, to be fair, if the can force you to do anything then the MITM capability is less interesting). So while this scheme benefits the operator, it provides negligible benefit to the client.

* You are reliant on the secondary CA to remain static (or having a backup CA) - this is the same problem as the original simply shifting the capability up one level - maybe this is OK.

Overall, this approach does provide more flexibility to the operator of the site - but provides no to negligible additional security on the client side (it upgrades the capability from being able to mimic any CA to being ale to mimic a specific CA), and may even put clients at greater risk - since there is now an additional avenue of certificate rotation which means extra code, extra verification to mess up etc.

These were a few thought that jumped into my brain - I would like to see a more detailed threat model / paper exploring some new schemes as I think there are wins in this space that haven't been realized yet - and there maybe improvements / clarifications which can improve this model further.

Reply on news.ycombinator.com