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.
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.
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.
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.
"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.
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.
Surely Google, master of advertising, has promoted this to all the people that matter.... OTOH, I've been running my own website for 20 years, and this is the first I've heard of it, too. But, then, Alexa hasn't been ranking me for a few years now - not that I care, just how the world has been turning.
I suspect it's the technical problems that they don't feel like solving and the low uptake is just an excuse to ignore the hard problems.
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 in.
.. 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.
A government is a body of people notably ungoverned - AC
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 inaccessible to JavaScript (like the URL bar) in which case the browser hashes it.
Secure Remote Password is a new (20 years old?) algorithm that makes the hashing secure from John the Ripper. With SRP there is no need for any reliance on CAs for most important transactions.
All that said, browsers should warn if the public key changes unexpectedly, much like SSH.
. As a career security professional,
As a career security professional, what is the one thing you wish programmers understood (or did differently) about security?
"First they came for the slanderers and i said nothing."
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" field in a form. What happens if the enter several megabytes in that field? What if they enter SQL code there? How can things break? Perhaps your software retrieves something over the internet. What happens if that retrieval stops half way through? What if the short text you meant to retrieve is instead several megabytes? What if it's JavaScript? How can things break?
The other thing is please have a ten minute conversation with me about your design, and a ten minute conversation about the implementation. After 20 years, I know the common problems, so I pretty much know where your main vulnerabilities will probably be as soon as you mention certain keywords. When you say "user downloads the file", or "download.php" or other similar words, there are three vulnerabilities that immediately spring to mind. You'll probably have two of the three in your application, unless you consult with a security person.
I can do a lot of good in making your application more secure not only in terms of confidentiality but also in terms of reliability if we have three short discussions:
Review your overall design / architecture up front
About 25% into the project, review more detailed implementation decisions (such as which hash is being used)
Near the end of the project, let me browse your source code and run a static analysis that looks for constructs such as "exec" and "system", and other red flags.
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.
OMG facts!
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.
"CAs are also out of the picture if you want them to be, using DANE you can use either self-signed certificates for your server or create your own local issuing authority for your certificates. End of problem with not trusting CAs, you only have to trust yourself."
trusting the CA's should be a user/admin choice not a manufacturer of the OS/Device
basically a one size fits all approach to a Certificate Authorities is rather silly