Fixing HPKP with Certificate Constraints
Last updated on: October 21, 2021
This is the third post in my series on HPKP. In my first post I declared HPKP dead, and in my second post I explored the possibility of fixing it by introducing pin revocation. Today I will consider an entirely different approach to make HPKP much safer, by changing how it’s activated.
In my previous blog post I argued that the biggest flaw of HPKP is that it doesn’t tolerate failures. That’s why I offered pin revocation as a solution. In my approach, the CAs’ existing OCSP infrastructure is used for the revocation, keeping things simple. The main disadvantage of the proposal is that there is deep distrust of both CAs and also no faith that they will maintain rock-solid revocation infrastructure.
Rethinking the problems with HPKP, I decided that I could attempt to solve them from another angle. To summarise, there are two big problems with HPKP: 1) it’s too easy to activate by anyone who can set HTTP response headers on your site and 2) there is no way to recover from failure. This incredibly low activation bar allows deployments that haven’t been thought through, activation by mistake, and even malicious pinning. The lack of failure recovery makes it very dangerous.
Certificate Constraints
It recently occurred to me that we could fix things largely by allowing HPKP activation only on the certificates that allow it. Technically, this could be achieved by placing a special OID in the certificates when appropriate. If the OID is there, browsers pin, otherwise they don’t.
With this feature in place, CAs could designate certain intermediates as suitable for pinning, guarantee public key longevity, and place the appropriate OIDs in them. Because this is a special type of certificate, it’s not something that you’d get by default. And, even if you did, recovering from failure is as easy as getting a new certificate.
If we really wanted to—for the brave—we could use a different OID to allow pinning to the leaf, in which case HPKP would be more difficult to activate, as secure as it is today in preventing MITM attacks, but there wouldn’t be a way to recover from failure. In this case the CAs wouldn’t need to promise key longevity, but they would still operate as gatekeepers to make malicious pinning less likely. Honestly, I don’t think this OID is a good idea. Those rare companies that wish to pin can still fallback to static pinning (embedded in the browser code). Even though static pinning is inefficient, there’s so few of those who might be interested that it doesn’t really matter.
The most efficient and most secure way way to pin today is to get a pair of intermediate certificates from different CAs and pin to them. Obviously, only wealthy organisations can do that. With certificate constraints, nothing would change, as their intermediates would just need to have the correct OIDs in place.
Conclusion
Are there any drawbacks to HPKP with certificate constraints? You could argue that it makes pinning more expensive because it reduces the pool of CAs from which you can get your certificates. However, the certificate expense is only a fraction of the overall cost of pinning, so I think that the difference doesn’t really matter.
The best thing about this approach is that the browser vendors would only need to add a tiny amount of code to make it happen. Most of the work would be in standardising the OIDs.
I’m not fully aware of how HPKP should be implemented.
but what is the advantage of HPKP above CAA.
as far as I can see CAA is based on registrar level where HPKP is applied on browser level
or would this be helpful when you don’t trust your registrar either.
Regarding HPKP implementation, I am writing a blog post about best practices that will go into some detail about how to best approach deployment. It involves creating long(er) term cryptographic identities and tying your web site to them. It can be tricky. For now, you can read my previous blog posts on HPKP, all linked here.
The advantage of HPKP is that it can in theory 100% protect from malicious certification authorities. Once all CAs implement everything correctly (this is work in progress), CAA should 100% protect from automated issuance, and would need to go past a human otherwise. The main advantage of CAA is that there is far less damage potential!
HPKP is dead, but You still do not check DNSSEC/TLSA Records for Websites.
Every month there are more Websites having TLSA Records, but this is a slow process.
You have the chance to speed this up by providing an A++ Level for sites with DNSSEC/DANE/TLSA.
Wouldn’t it be better to implement new standards like DANE than riding dead horses like HPKP?
Hi EricB,
First of all, HPKP is considered dead now, but it wasn’t back when this post was published. Nevertheless, there is value in researching the problem domain in order to find better solutions, and that’s exactly what this post did. HPKP is now dead, but not because it was impossible to fix, but because one browser vendor decided to direct their efforts elsewhere. Admittedly, few were interested in doing HPKP properly.
Regarding your questions about SSL Labs features and direction, they are not for me to answer (because I am no longer involved). That said, DANE is also a dead horse when it comes to port 443 because browser vendors don’t want to support it.