FotolEdhar - Fotolia

HTTP public key pinning: Is the Firefox browser insecure without it?

HTTP public key pinning, a security mechanism to prevent fraudulent certificates, was not used by Firefox, and left it open to attack. Expert Michael Cobb explains how HPKP works.

A certificate pinning flaw in Tor and Firefox web browsers left users open to man-in-the-middle and malicious add-on attacks. Mozilla uses its own process, in place of the typical HTTP public key pinning for add-on updates, which had a flaw that made it ineffective. How important is certificate pinning for browsers? What should enterprises do to ensure that installed browser add-ons are secure?

HTTP public key pinning (HPKP) is an important security mechanism when used in conjunction with other communication security protocols to prevent hackers from using wrongly issued digital certificates.

Google's Chrome browser, for example, successfully detected a compromise in the root certificate authority DigiNotar, which resulted in a fraudulently issued SSL certificate for Google.

Browsers typically validate a web server's certificate by checking its signature hierarchy; the my web server cert is signed by the intermediate cert, which is signed by the root cert, and the root cert is listed in a device's trusted certificates store. However, any certificate authority (CA), or intermediate issuer, can issue a certificate for any website. This means a compromised or rogue CA could wrongly issue certificates for a web server, even if it has no official relationship to the owner of the domain name.

The problem of fraudulent digital certificates is growing, and last year saw several instances of certificates being incorrectly issued: Google found unauthorized digital certificates for several of its domains issued by the China Internet Network Information Center, China's main government-run CA. And Netcraft found fake banking websites using domain-validated SSL certificates issued by Symantec, Comodo and GoDaddy.

To combat this risk, HPKP allows an HTTPS web server to pin the fingerprint of specific public keys that the browser can trust. After a user visits a site, its HTTP public key pinning policy is stored by the browser so it can reject any future connections that use different, nonwhitelisted keys. This effectively reduces the number of CAs that can issue certificates for a site, which, in turn, reduces the possibility of a man-in-the-middle attack due to a compromised CA.

A blog post from a security researcher known as movrcx, and subsequent investigation by researcher Ryan Duff, found that Firefox uses its own static key pinning method, and not HPKP, for Mozilla certificates. This method is flawed, and could allow an attacker with a forged certificate for to cause any Firefox or Tor Browser user (the Tor Browser is based on Firefox) on an attacker-controlled network to receive malicious updates for add-ons they have installed. This could lead to arbitrary code execution on the targeted device with no user interaction.

Although Mozilla pins the certificate for, it appears that if any certificate is compiled directly into Firefox, it is recognized as BuiltIn, and treated as a statically pinned certificate. The only requirement for validation of statically pinned certificates in Firefox is that the certificate validates through to a CA built into the Firefox certificate store, thus skipping normal HPKP checks. This attack requires the perpetrator to obtain a forged certificate for that validates up to a Firefox recognized CA, and though that's not an easy task, it's within the capability of many threat actors -- in 2011, a fake certificate was issued for by Comodo.

To ensure all communication to and from a website is authenticated and encrypted, and that HPKP plays an effective role, administrators need to also implement HTTPS, HTTP Strict Transport Security (HSTS) and HSTS preloading -- HSTS instructs browsers to only communicate with a server using secure HTTPS connections.

However, hardly any HTTPS websites use HTTP public key pinning. According to Netcraft's March 2016 SSL survey, less than 0.1% of certificates found were served with the HPKP header, and a third had been misconfigured. The risk of incorrectly deploying HPKP headers is certainly deterring many from using it, as a small misconfiguration can result in a website becoming inaccessible. Once set, a pin remains valid for a period of time.

Although HPKP offers a robust defense against website impersonation, it really only makes sense for large and high-profile websites because fraudulently issued certificates are pretty rare, and they are more likely to be used to impersonate popular and well-known websites.

Administrators concerned about fraudulent digital certificates may well find Certificate Transparency (CT) a safer and easier solution. It's a protocol proposed by Google for publicly logging every certificate that's issued by compliant CAs, the long-term goal being that browsers will refuse to honor certificates that do not appear in a public CT log. Unlike HTTP public key pinning, it also defends against rogue root certificates installed locally on users' devices.

Mozilla and Tor have fixed the problem and have stated that they're not aware of any malicious certificates in the wild. The industry is still searching for the best way to combat fraudulent digital certificates, and they remain difficult to defend against. Every internet user is reliant on CAs and the digital certificates they issue to provide trust and to secure their online activities, and users and their data are very exposed when that model of trust is broken. Enterprises at risk from nation state attacks must carefully monitor for news of potential rogue certificates and the services that may be affected, so they can mitigate any risks as soon as possible.

Next Steps

Learn how the Vawtrak banking Trojan uses SSL pinning to avoid detection

Read about how Symantec was discovered improperly issuing certificates by Certificate Transparency

Discover how to tell authentic and fraudulent digital certificates apart

This was last published in February 2017

Dig Deeper on Identity and access management