Subscribe to our Threatpost Today newsletter

Join thousands of people who receive the latest breaking cybersecurity news every day.

The administrator of your personal data will be Threatpost, Inc., 500 Unicorn Park, Woburn, MA 01801. Detailed information on the processing of personal data can be found in the privacy policy. In addition, you will find them in the message confirming the subscription to the newsletter.

*

*

I agree to my personal data being stored and used to receive the newsletter

*

I agree to accept information and occasional commercial offers from Threatpost partners

The administrator of your personal data will be Threatpost, Inc., 500 Unicorn Park, Woburn, MA 01801. Detailed information on the processing of personal data can be found in the privacy policy. In addition, you will find them in the message confirming the subscription to the newsletter.

Google to Ditch Public Key Pinning in Chrome

Google says upcoming version of Chrome will deprecate the browser’s support for HTTP public key pinning.

Google said that in an upcoming version of Chrome it will deprecate the browser’s support for HTTP public key pinning. Instead, it will adopt the “safer” more flexible solution of Expect-CT headers.

HTTP public key pinning (HPKP) is a browser security measure that protects against an SSL certificate impersonation attack via the use of mis-issued or fraudulent certificates. The technology was meant to thwart man-in-the-middle and malicious add-on attacks.

“This will first remove support for HTTP-based PKP (‘dynamic pins’), in which the user-agent learns of pin-sets for hosts by HTTP headers. We would like to do this in Chrome 67, which is estimated to be released to Stable on 29 May 2018,” wrote Chris Palmer, senior software engineer at Google in a developer forum on Friday.

Google originally described HPKP this way when it rolled out the feature in May, 2015 with Chrome 47: “(The) standard allows websites to send an HTTP header instructing the browser to remember (or ‘pin’) parts of its SSL certificate chain. The browser will then refuse subsequent connections that don’t match the pins that it has previously received.”

Fast forward two years, and Google argues while public key pinning defends against certificate mis-issuance, it runs the risk of leaving website admins open to difficulties selecting a reliable set of keys to pin to. In addition to that, Google points out adoption of PKP is low, citing data that of the Alexa Top 1 Million sites a paltry 375 were using a variant of HPKP.

“PKP offers a way to defend against certificate misissuance, by providing a Web-exposed mechanism (HPKP) for sites to limit the set of certificate authorities (CAs) that can issue for their domain,” Palmer wrote. “However, this exposes as part of the Open Web Platform considerations that are external to it: specifically, the choice and selection of CAs is a product-level security decision made by browsers or by OS vendors, and the choice and use of sub-CAs, cross-signing, and other aspects of the PKI hierarchy are made independently by CAs,” Palmer wrote.

Michael Fowler, president of the Comodo certificate authority, points out that static pins, which are pre-loaded list of pins included by the browsers, are difficult to rapidly update, and not scalable.

“‘Badness’ stems from the ability to completely break a site if used incorrectly – pinning keys which are then subsequently lost or unavailable will effectively break your site and render it inaccessible,” Fowler said in an interview with Threatpost.

“There was also the possibility of being held to ‘ransom’ if someone was able to breach a webserver and send pins for keys you did not hold, you’d again have an inaccessible site until the keys were provided for a ransom (or not).”

As an example, Fowler said, when one website, Smashing Magazine, was updating an expiring SSL certificate it enabled HPKP. In a blog post titled “Be Afraid Of HTTP Public Key Pinning” it ran into major problems when browsers with the old HPKP policy received a “Your connection is not private” message when visiting the site.

Instead of HPKP, Google is advocating the use of Expect-CT headers.

“To defend against certificate misissuance, web developers should use the Expect-CT header, including its reporting function. Expect-CT is safer than HPKP due to the flexibility it gives site operators to recover from any configuration errors, and due to the built-in support offered by a number of CAs,” Palmer said.

The HTTP Working Group explains Expect-CT as allowing web host operators to instruct browsers to expect a valid Signed Certificate Timestamps (SCTs) to be served when connecting to web sites.

“By combining Expect-CT with active monitoring for relevant domains, which a growing number of CAs and third-parties now provide, site operators can proactively detect misissuance in a way that HPKP does not achieve, while also reducing the risk of misconfiguration and avoiding the risk of hostile pinning,” Palmer said.

Authors

Threatpost

InfoSec Insider Post

InfoSec Insider content is written by a trusted community of Threatpost cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.

Sponsored

Sponsored Post

Sponsored Content is paid for by an advertiser. Sponsored content is written and edited by members of our sponsor community. This content creates an opportunity for a sponsor to provide insight and commentary from their point-of-view directly to the Threatpost audience. The Threatpost editorial team does not participate in the writing or editing of Sponsored Content.