Slashdot Mirror
Google To Remove Public Key Pinning (PKP) Support In Chrome (bleepingcomputer.com)
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.
"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.
"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 know what a CSR is... so lets not do it.....?
What I want to see in an argument is technical and statistical evidence that useful in making an informed decision regarding tradeoffs. Just saying something is "hard" or not "guaranteed" isn't communicating objectively useful information.
There is a risk of rendering a site unusable.
HSTS offers that same risk. Case in point on one of my machines Wikipedia would not work without not even allowing me to accept risk the site my be compromised without switching to firefox because for some reason one of the globalsign root certs were missing from my operating systems root database. In other cases accidentally allowing certs to expire completely cuts off access to sites. Those who enable these features know (or should know) the risks and tradeoffs. There are other issues with HSTS such as unrelated services that happen to be on the same domain listening on other ports being adversely affected by HSTS.
There is a risk of hostile pinning, should an attacker obtain a misissued certificate. While there are no confirmed or rumored cases of this having happened, the risk is present even for sites that donâ(TM)t use PKP.
The circular logic embodied by this statement is hilarious. Raison d'etre for PKP is protection against mississued certificates. Naturally most security latches necessarily increase lockout risk. The question of import is what affect does this have in the real world?
Use of every single bit of security technology involves tradeoffs that must be carefully considered. Just listing some with no context and no statistical evidence to inform any useful evaluation of tradeoffs is not really make a serious argument.
None of the excuses listed in Chris's post are new. They were all well known when the feature was implemented. The fact usage on a relative basis was always likely to be low for a feature like this must have also been well understood going in.