What HPKP is but isn't

HTTP Public Key Pinning (HPKP) [RFC 7469] is very powerful if configured correctly. It has the ability to protect against the most sophisticated targeted attacks that seriously threaten the security on the Internet, for all of us. But, with great security comes great responsibility. If HPKP is deployed into a production environment without being thoroughly tested and designed, the website may be inaccessible for all the previous visited clients. The fear of incorrectly deploying an HPKP-policy could scare the security-responsible into not using the security mechanism at all. So is it worth it? Should you use HPKP?

This article is more focused on what HPKP isn’t because I assume that the reader has a reasonable understanding about the subject already.

What HPKP is

HTTP Public Key Pinning is simply a way for the web server to tell the client which certificates that are allowed to be used in a TLS/SSL-connection to the server. The server also tells the client for how long they should remember this rule for. These certificates are hashed using the SHA hash algorithm, mostly because we do not want to send too much data in the headers but there could be other advantages as well.

That’s all you need to know!

What HPKP isn’t

HPKP can’t protect in all situations. It doesn’t protect when the attack is within the local network. This is not entirely true, but it’s meant to be like this due to debugging purposes.

Chrome and Firefox will happily allow certificates that are locally imported and trusted. If you have ever used Fiddler4, Charles Proxy or even Burp Suite, you most likely have proxied HTTPS-traffic before, and as you know, this means that you need to import a root certificate in order to read the traffic.

PS. Facebook is HPKP-preloaded into Chrome.

So that makes sense because it’s only valid if the root certificate is locally imported and trusted, or if the trusted root certificate has directly issued a leaf to the domain.

If you are familiar with certificate pinning (not the same thing as HPKP) this is never the case; you can’t use a local root certificate that issues valid certificates in order to sniff traffic. In many mobile apps certificate pinning is used to avoid exposing sensitive data flow such as API endpoints.

So HPKP does not protect against local attacks, such as malware intercepting traffic. As long as the malware has the ability to get a root certificate installed on your machine, there’s nothing HPKP can do. You may have heard this before as Superfish was something that almost everyone talked about for a while.

The protection against this is to review your certificate store. You can use a program called RCC (Windows) which simply scans your certificate stores and compares them to a “baseline”.

HPKP is [not] TOFU

HPKP could be Trust On First Use (TOFU) which is an easy but far from perfect solution. The concept with TOFU could be summarized as:

• Do not apply if you haven’t used the service before
• Only the first connection must be trusted

As a website owner you can’t guarantee that the end user will use your website securely, even if you provide HPKP.

For example, if a person in a restricted country tries to access your website for the first time, it could be possible for the government to intercept traffic between the client and your server if they have a valid certificate for that domain (see DigiNotar incident and 2011 COMODO Incident). Now, this example is highly unlikely today, but it has been made before and if HPKP were to be used in the above example – it wouldn’t protect the user. This is because the client had not yet received the website’s HPKP-policy.

However, today the biggest websites are well-protected against this (in browsers). This is mostly because they don’t use TOFU. Big websites such as Facebook, Twitter and Google already have their HPKP-policy hardcoded into Chrome and Firefox.

However, there are other protections against rogue certificates, attempting to prevent CA from issue certificates the domain holder did not ask for. One of these methods are the promising DNS Certification Authority Authorization Resource Record (CAA) [RFC6844] which, publicly via a DNS-record, tells which CA that are allowed to issue certificates for the domain. Of course, all CAs (and domains) should support CAA for this to be an effective protection.

However, even if preloaded HPKP and CAA were in use, this would not certainly protect against all attacks, for example:

• The private key could be stolen
• An attacker could issue a leaf certificate from the CA that both follow the HPKP,-and CAA-policy

Especially the bolded. Read below.

The chain is the weak link

An HPKP-policy is, simply put, a chain of public certificates that the connection must be built upon. If one valid certificate exists in the certificate path, the connection will be considered as secure – because the server told us which certificates are only allowed to be used when a connection to the website is made.

The leaf certificate is the one that is unique to the domain. The root,- and intermediate certificate are the same for everyone else that uses the exact same leaf certificate. For example; a website uses HPKP and has pinned COMODO’s intermediate to be used as a backup key in the provided HPKP-policy.

If an attacker had the possibility to get a certificate for the domain via COMODO, they could bypass the HPKP. This is because the website said that in a client’s certificate path, COMODO’s intermediate is allowed to be used. There are several protections against this. The safest thing is never to pin any intermediate nor root certificates, instead only pin leaf certificates because they require the private key to be uniquely generated. This is much easier said than done; pinning leaf certificates is very risky because losing the private key will make it impossible to get the key back.

Another protection would be to have preload-HPKP in combination with CAA, where the CAA-record points to a CA that is not listed in the preloaded HPKP-policy. But it should be safe to pin intermediate certificates due to Certificate Transparency (CT) [RFC6962] that are being used right now. CT is simply a huge log of certificates so we can publicly see if a CA has issued a certificate to a domain. With this log we can easily spot if a CA has issued a certificate to our domain that we did not ask for, and then we can revoke those certificates. This has happened before, with the Facebook Incident where someone succeeded to issue certificates to fb.com via Let’s Encrypt.

Summary

So should you use HPKP? Yes, you should. If you pin correctly, the chance of everything going south is pretty small.

Some tips for those who are thinking about deploying HPKP:

• Start off with Public-Key-Pins-Report-Only
• Pin intermediates that have a long expiration
• Use a short max-time (hours or a few days)
• Keep a backup of all your certificates in a safe place!

Due to new security mechanisms being developed and used the chance of HPKP-bypasses will become more and more unlikely.

HPKP has a lot of potential and it will be interesting to see how HPKP will develop in the future.

Author: 

Chloe, Security Researcher
Twitter: @dotchloe