Skip to main content Logo (IEC resistor symbol)logo

Quis custodiet ipsos custodes?
Home | About | All pages | RSS Feed | Gopher

Chrome 68 is depcrecating HPKP (HTTP Public Key Pinning)

Published: 12-06-2018 | Author: Remy van Elst | Text only version of this article

Table of Contents

HPKP removed from Chrome 68

In 2014 I published an article on HPKP, http public key pinning. It allowsa site operator to send a public key in an http header, forcing the browser toonly connect when that header is found. It was ment to redice the risk of acompromised certificate authority (since any CA can create a certificate for anywebsite). Quite secure, but it was often wrongly configured, forgotten untilcertificates expired and there were some security issues like a false pin. Late2017 Google announced that HPKP would be removed in Chrome 68 and that versionis released now, so HPKP is no longer supported.

A certificate authority, like Comodo, because they are trusted by every browser, can issue a certificate for any site (so, But, the Netherlands Government (Staat der Nederlanden) or the Hong Kong Post office (China government) are trusted as well, thus are also able to issue a certificate for Now, there are all kinds of rules prohibiting that, but as I've shown by getting a certificate for a website I don't own, just as this guy for Microsoft, that it is prohibited by rules doesn't mean it is not technically possible. HPKP was meant to prevent that, by hardcoding a certificate for your site into a browser.

If you like this article, consider sponsoring me by trying out a Digital OceanVPS. With this link you'll get $100 credit for 60 days). (referral link)

The Google development announcement can be found here, where they describeand discuss the intent to remove the feature from chrome.

ZDNET has an article going into more detail on what goes wrong when youforgot about Key Pinning when a certificate expires:

This scenario happened to Smashing Magazine when it was updating anexpiring SSL certificate. It enabled HPKP and set the policy for 365 days. Afterrolling out new valid certificates, all browsers with the old HPKP policycouldn't visit the site. Also, the new HPKP policy did nothing to update the oldone.

Replacement for HPKP, Expect-CT header?

Google wants the Expect-CT header to replace HPKP. This header allows webhost operators to instruct user agents (browsers) to expect valid SignedCertificate Timestamps (SCTs) to be served on connections to these hosts. Whenconfigured in enforcement mode, user agents (UAs) will remember that hostsexpect SCTs and will refuse connections that do not conform to the UAsCertificate Transparency policy.

There is no automatic detection of invalid certificates or rouge certificates.As far as I understand you must configure and monitor the CT logs yourself tofind rouge certificates. I use this site and get emails when a certificatefor a certain domain is found.

This page has a little bit more on the replacement:

By combining Expect-CT with active monitoring for relevant domains, which agrowing number of CAs and third-parties now provide, site operators canproactively detect misissuance in a way that HPKP does not achieve, while alsoreducing the risk of misconfiguration and avoiding the risk of hostile pinning,(Chris) Palmer said.

Google's Certificate Transparency project is an open framework for monitoringand auditing SSL certificates. The goal behind the project is detection of mis-issued/malicious certificates and identification of rogue CertificateAuthorities.

Read more about the Expect-CT header in the RFC. To read more aboutCertificate Transparency, check the site here.

As I'm unsure on how the actual header works, for example what defines when anerror is given, I'm not recommending it yet, until I've done more research.

Removing HPKP on

I removed HPKP about half a year ago from the servers hosting by setting the max-age portion of the header to 0, that tells existingbrowsers that have HPKP cached to invalidate the known time. Otherwise, whenchanging the certificate, the browser would still have old information thusgiving errors.

After 4 months, I actually changed the webserver configuration to remove theHPKP headers:

$ curl -I https://raymii.orgHTTP/2 200 server: nginx/1.10.3 (Ubuntu)date: Tue, 12 Jun 2018 09:39:01 GMTcontent-type: text/htmlcontent-length: 376last-modified: Tue, 05 May 2015 17:21:00 GMTetag: "5548fbfc-178"expires: Thu, 12 Jul 2018 09:39:01 GMTcache-control: max-age=2592000strict-transport-security: max-age=63072000; includeSubdomains; preloadreferrer-policy: originx-xss-protection: 1; mode=blockcoffee: Blacktea: Earl-Gray; Hotx-frame-options: DENYx-content-type-options: nosniffx-ua-compatible: IE=Edge,chrome=1cache-control: publicaccept-ranges: bytes

As you can see, no Public-Key-Pins header. If you have HPKP and want to removeit, make sure to first set the time to 0 and let that run for a few months.

Tags: apache, blog, expect-ct, hpkp, https, lighttpd, nginx, security, ssl, tls