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.
"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.
444% growth (Score:4, Funny)
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.
Re: (Score:2)
444% every 17 months, 286% per year, in 5 years at that growth rate they will be up to 77%... patience ;-)
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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.
hpkp 'backup' certs - 'insurance' (Score:2)
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.
Re: (Score:1)
Since I've implemented HPKP multiple times including for 3-month Let's Encrypt certificates with over a year worth of certificate rotation I know how it works and what you wrote is simply incorrect.
The CA pinning is another, unrelated feature and is called DNS CAA in which you put in a list of approved CAs that can generate certificates for your domain in the DNS system as a CAA record.
Re: (Score:2)
I am sure it is possible to do hpkp but since dnssec [tlsa] is easier imho and with csp's the need to have a backup ca means its a lot of work for something most do not give a stuff about.
A backup ca infers that the real ca is untrustworthy. What should a ca be? My head hurts on that issue.
DANE and TLSA (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
Why mention the registrar at all? DANE is built on DNS, so other than delegation of nameservers your registrar is out of the picture (unless they're also your DNS provider). The only trust relationship needed is between you and your DNS provider, and you can change your DNS provider if you don't trust your current one. Or if you're truly paranoid you can run your own nameservers.
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
Re: (Score:2)
Exactly - DANE and TLSA (Score:2)
"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
Crazy Order of Magnitude increase for PKP adoption (Score:3, Informative)
"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.
Re: (Score:2)
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.
Specious nonsense (Score:2, Informative)
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
Re: (Score:2)
Specific support is stupid... (Score:2)
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.
Interesting concept, but in practice plugins get h (Score:2)
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
Re: (Score:2)
. As a career security professional,
As a career security professional, what is the one thing you wish programmers understood (or did differently) about security?
A) How can it break? B) Seek my suggestions (Score:2)
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
Re: (Score:2)
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).
ob_end_flush, X-Send-File, basename() (Score:2)
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.
Re: (Score:2)
Comment removed (Score:4, Insightful)
If available, better use it (Score:2)
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
Phishing is the problem, not CAs, use SRP (Score:2)
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
Re: (Score:2)
All any of this stuff does anyway is make the connection secure. The file system itself can still be wide open and unencrypted.
Encryption or no-encryption makes no difference to a filesystem while the system is still on. Especially if you are running spyware software.
Disk encryption ONLY kicks in if you fully powrer of your device, and only then. The rest of the time it is essentially unencrypted and just wasting more CPU power reading.
More changes to web security (Score:2)