Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Chrome Google Chromium Encryption Privacy

Google To Remove Public Key Pinning (PKP) Support In Chrome (bleepingcomputer.com) 51

An anonymous reader writes: Late yesterday afternoon, Google announced plans to deprecate and eventually remove PKP support from the Chromium open-source browser, which indirectly means from Chrome... According to Google engineer Chris Palmer, low adoption and technical difficulties are among the reasons why Google plans to remove the feature from Chrome.

"We would like to do this in Chrome 67, which is estimated to be released to Stable on 29 May 2018," Palmer says. The proposal is up in the air, and users can submit opinions against Google's intent to deprecate, but seeing how little PKP was adopted, it's most likely already out the door. A Neustar survey from March 2016 had PKP deployment at only 0.09% of all HTTPS sites. By August 2017, that needle had barely moved to 0.4% of all sites in the Alexa Top 1 Million.

This discussion has been archived. No new comments can be posted.

Google To Remove Public Key Pinning (PKP) Support In Chrome

Comments Filter:
  • 444% growth (Score:4, Funny)

    by eminencja ( 1368047 ) on Saturday October 28, 2017 @03:01PM (#55450521)

    deployment at only 0.09% of all HTTPS sites. By August 2017, that needle had barely moved to 0.4%

    That's 444% growth. If PKP was a startup, its stock would surge.

    • 444% every 17 months, 286% per year, in 5 years at that growth rate they will be up to 77%... patience ;-)

    • The problem with it was that it was off by default, not on by default. When Chrome throws up a warning that you haven't paid your CA for a license to put a web page online and people will be scared away from your site if you don't, its enabled by default. Pinning, the same thing that SSH has been successfully doing for twenty years, was turned off by default for web sites. So now they can say it didn't work, and we can all go back to waiting for PKI to start working, as we've been doing for close to thir
      • When Chrome throws up a warning that you haven't paid your CA for a license to put a web page online and people will be scared away from your site if you don't, its enabled by default.

        Apparently you've never heard of Let's Encrypt? No one is required to pay for a "license" to put a secure web page online these days; you can get CA domain-validation certificates for free. There is no excuse left for not using properly signed certificates.

        • Apparently you've never heard of Let's Encrypt? No one is required to pay for a "license" to put a secure web page online these days

          With Lets Encrypt you still pay, it's just in terms of time and effort, not money. No matter how you slice it, you still need to ask a CA for permission to put a secure web site online. You can't just stand up a server and get crypto, even though SSL/TLS allows for that. The browser vendors have made sure of that.

  • Why would a site buy tls certs from a ca and not use them? - eg an active and backup ca provider since better tls certs have 'insurance' quite how you claim it is another matter.

    Sure letencrypt made it easier to have a backup ca (random certs mean you need to apparently edit your but hpkp config often for hashes seems that hpkp is disaster.

    If you did not have a backup ca (caa record needs to reflect it also) then hpkp is deemed incomplete. I can see reasons.

  • DANE and TLSA (Score:5, Insightful)

    by Todd Knarr ( 15451 ) on Saturday October 28, 2017 @03:55PM (#55450643) Homepage

    I'd prefer, rather than key pinning, DANE and TLSA were adopted widely. That'd allow not only attaching a specific certificate to a site but running a site without needing to go to a third party for certificates. Combined with DNSSEC to prevent forgery of the DNS records involved it's more secure than the CA chain-of-trust because the site owner/operator's unlikely to issue his own certificates to malicious parties through error or negligence.

  • by CrashNBrn ( 1143981 ) on Saturday October 28, 2017 @04:16PM (#55450689)

    "that needle had barely moved" in the last year, it only increased by an order of magnitude and we will be deprecating in 6 months.

    Feel free to comment, but as usual when we decide to drop features, nothing you say can nor will make a difference. Have a Nice Day.

  • My default operating position is to expect browser vendors to protect CA/Government interests at all costs. The current system gives every competent government in the world a back door. Anything that jeopardizes this by effectively deterring or enabling detection of Government and criminal enterprise subversion attempts is bad for business.

    It is hard to build a pin-set that is guaranteed to work, due to the variance in both user-agent trust stores and CA operations.

    Hard to install and manage TLS certificates especially if you don't know what your doing so lets not use them. I'm tired of helping people setup TLS who don't even kno

  • All security should be implementable through plugins and addons. Every imaginable scheme should be implementable even if it's insecure or stupid. Then have an audit advisory of security schemes for implementations and interactions. There should be no security reason for you to have to use a newer version of software. Security should be separate.

    • That's an interesting idea, and I see why you say that. IPSec (mostly used for vpns) is an example of this done fairly well. IPSec and ISAKMP don't specify any specific ciphers, different types of authentication can be dropped in, etc.

      On the other hand, plugins are very frequently the source of security problems. Third-party plugins have a MUCH worse security record than major software such as Chrome. As a career security professional, I'd prefer that essential security functions be designed in, and baked

      • . As a career security professional,

        As a career security professional, what is the one thing you wish programmers understood (or did differently) about security?

        • I have two top things. When developing software for a disk-based operating system where everything happens on the local computer, it made sense to think in terms of "how can I make this work?" Programmers thought in terms of starting with (valid) input and ending up with usable output.

          When your software is exposed to the internet, it will be attacked hundreds or thousands of times a day, so the question isn't so much "how can it work?" but "how can someone break it?". Your web page has a "name" fi

          • When you say "user downloads the file", or "download.php" or other similar words, there are three vulnerabilities that immediately spring to mind.

            What security problems does that give you? Unless you're thinking of some kind of XSS (or similar).

            • Following my own advice, I'll give you solutions instead of problems.

              Use basename() rather than writing your own code to avoid filesystem transversal.

              Call ob_end_flush() before sending the file.

              Use X-Send-File on Apache or lighttpd. Of X-Send-File isn't available on your server, use readfile() rather than reading the file but by agonizing bye.

  • by nightfire-unique ( 253895 ) on Saturday October 28, 2017 @07:10PM (#55451111)

    .. to care deeply about security, the biggest derp I personally struggle with is the fact Chrome, in 2017, still isn't able to remember user-signed certificate fingerprints. It's bizarre.

    I generally prefer Chrome to Firefox, but have to use the latter for most of my internal applications if I want any reasonable assurance that my SSL session is actually secure.

  • HPKP is a dangerous protocol since a mistake can lock your users out of your web site for a while.

    But ignoring it comes with a threat: if an attacker manages to impersonate your server, he can send bad HPKP headers that will lock users out. The only defense against that is to actually use HPKP.

    HPKP seems to go the way of the Dodo for Chrome, but it is still available on other browsers

  • The CA is irrelevant. Nobody looks at the URL in practice (other than pedantic slash dot readers), as long as it has some padlock it is thought to be secure.

    The problem is that passwords should never be sent to the server in the first place. Just proof of possession. Then there would be minimal danger.

    The old web had a solution to this of sorts, hash the password with a nonce and send the result back. That approach needs to be brought back. Users need to learn to only type passwords in a place that is

  • We should be focusing on fixing the existing technical barriers to entry around securing server and browser interaction. This is a cool solution but it is definitely an overengineered one.

Doubt isn't the opposite of faith; it is an element of faith. - Paul Tillich, German theologian and historian