Slashdot Mirror
SHA-1 Cutoff Could Block Millions of Users From Encrypted Websites (csoonline.com)
itwbennett writes: As previously reported on Slashdot, browser makers are considering an accelerated retirement of the older and increasingly vulnerable SHA-1 function. But Facebook and CloudFlare are warning some 37 million users of old browsers and operating systems that don't support SHA-2 will be left without access to encrypted websites. The majority of them are located in some of the "poorest, most repressive, and most war-torn countries in the world," CloudFlare's CEO Matthew Prince said Wednesday in a blog post. Facebook has solved this problem by building a mechanism that allows its certificates to be switched automatically based on the browser used by the visitor.
That even Windows XP support the latest browsers still... or at least some variant of them.
If they don't want to move on from IE 6, that's their god damn problem.
Some of the older Oracle products only support SHA-1. Upgrading to a newer version or Oracle will cost them millions. Won't someone think of the Oracle user base?
So let me see if I understand Facebook's approach here: there are non-secure certificates. Facebook will fix the problem by downgrade connections to use non-secure certificates. Bad guys would never pretend to need a non-secure certificate. Therefore, Facebook remains safe?
John
Some of the older Oracle products only support SHA-1. Upgrading to a newer version or Oracle will cost them millions. Won't someone think of the Oracle user base?
Nonsense. Postgres is free.
I have one of these old browsers, and I'm not being cut off of the we
"Most of the places that they say do not update are home of some of the worse kinds of people."
Sources? Even if this is true, the ratio of terrorist to non-terrorist is still probably quite small.
"And most of those relief agences are the ones that need it the most and can't afford to upgrade."
Wait, which is it? Relief agencies or 'worse kinds of people'?
Nice try. Brush up on your critical thinking and play again some time!
Oracle users deserve all the pain they can get!
Don't complain of neck pain after hanging yourself.
Fortunately, slashdot will remain accessible as it still hasn't entered the 2010's and added encryption yet!
At least we hope so.
Give the users some kind of feedback to know that SHA1 is being used by the site and that they should maybe get their shit together, but whether or not support is dropped should be up to the site administrator.
Cause that works so well for the existing "connection may not be secure" messages that the average person doesn't understand so they blindly continue on.
What I don't understand is that it is the browsers removing the access. If a website really wants to support the old clients/ciphers they are still free to do so.
What it really seems to be is that this will force some lazy sites to update their certs to not support only SHA-1. If so then they need to shut the hell up and protect their customers.
And most of those relief agences are the ones that need it the most and can't afford to upgrade.
Clicked 'Download Firefox Now'. Total cost: $0.
Have gnu, will travel.
ISIS has their own computer help line. I'd say the terrorists have better IT support than most 'mericans...
I've abandoned my search for truth; now I'm just looking for some useful delusions.
What is the point of developing in the browser if you are only going to support one specific version from one specific vendor?
.
Maybe a loss of Internet access is just the jolt they need to get off their butt and upgrade.
People running obsolete systems feed botnets and impede others from staying current.
This. The title of this article is very slanted; how about "SHA-1 Cutoff Will Shut Down Insecure Access" instead?
Can't upgrade because reasons? Go cry to whomever is creating that problem for you
Such crying would fall on deaf ears, as mobile device manufacturers routinely announced end of support not only for handsets that are still under 2-year financing but also for handsets that are still being sold in stores. And when "whomever" amounts to the "poorest, most repressive, and most war-torn countries in the world," as the article mentions, what recourse does one have?
The problem with that is that there is no actual way to detect that an old browser doesn't support SHA-2.
For example, older versions of Firefox/NSS since 2003 have supported SHA-2 server certificates, but not SHA-2 in TLS cipher suites as the MAC algorithm, which wasn't specified until years later.
The TLS ClientHello message does not specify which types of hash algorithm the client supports for certificates, only the list of cipher suites that the client supports.
Thus, Facebook, or anyone else, has no way of determining if a client really doesn't support SHA-2 server certificates.
What they are probably doing is assuming that clients that don't support SHA-2 MAC in TLS cipher suites . But that's a wrong assumption. Many older clients will be downgraded to SHA-1 server certificates as a result, even though they support SHA-2 certificates. And they will have no way of knowing that this happened.
-- Julien Pierre http://www.madbrain.com/blog
Most web servers do that automatically. I'd be willing to bet that 99.999% of the web servers in use do, actually. Even the ones that can't do SHA-1 anymore, still have multiple levels they support; the server should negotiate for the highest shared level. Why is this being painted as some sort of innovation Facebook has miraculously engineered? (Effectively) every single web server and web browser out there is already doing this...
It's irrelevant, anyway - PCI-DSS will mandate it at some point for any site that accepts credit cards (if it hasn't already: PCI-DSS already mandates that support for all versions of SSL is dropped, and "early TLS" is dropped - they've not defined "early TLS" but TLS 1.0 is known to be vulnerable to attacks already, and TLS 1.1 is structurally weak, so I bet within a year this will be clarified to mean "both TLS 1.0 and TLS 1.1 must not be enabled" by the webserver. By June 2016 you have to get rid of TLS 1.0 if you accept credit card payments.
Some quite recent browsers don't support TLS 1.2 by default (I think some fairly recent versions of Internet Explorer need TLS 1.2 switching on manually).
Oolite: Elite-like game. For Mac, Linux and Windows
Postgres is free.
PostgreSQL is free until the application that you just tried to migrate from Oracle Database to PostgreSQL throws a syntax error. Then it costs time (which is money) to fix the apps if they're in-house or free, or it costs money to either purchase an upgrade to add PostgreSQL compatibility to a proprietary application or to migrate entirely from a proprietary application for which PostgreSQL compatibility is not available. Or does PostgreSQL's PL/pgSQL parser accept all PL/SQL and MySQL syntax to allow it to be used by applications that expect some Oracle product?
Persistent login is a completely orthogonal problem to TLS certificate forgery. What's going on is that Mozilla and Facebook are continuing to make SHA-1 access available and dealing with forgeries on a reactive basis until enough of the user base has migrated to allow the proactive approach of allowing only SHA-256 access.
Why the hell do browser companies want to remove SHA1 support all together?
The whole point of a certificate is to validate that you are talking to the site you think you are talking to. If an attacker manages to obtain a certificate for facebook.com via a SHA1 collision attack then he can pose as facebook regardless of what certificate signature algorithm is used on the legitimate facebook server.
will they just stop support plain HTTP because HTTP is far more likely to be abused.
They aren't stopping it but they are trying to reduce the potential for abuse. Read up on http strict transport security.
Give the users some kind of feedback to know that SHA1 is being used by the site and that they should maybe get their shit together
Most users tend to ignore such feedback and even if they don't it can come too late. By the time they notice it the information can already be in the attackers hands.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
I fail to see how your organization failing to upgrade 10+ year out of date software is our problem.
Also... SharePoint. *ding*
I'm a good cook. I'm a fantastic eater. - Steven Brust
Try this: Allow connections from TLS 1.2 and TLS 1.0. But if the server detects that the client has fallen back to obsolete TLS, display an interstitial page once in each session, explaining the situation in a manner that correctly yet politely places the blame:
Then replace all "Check Out" buttons and links to manage saved payment credentials (if any) with a "Learn How to Check Out" that re-shows the interstitial.
To work around software restriction policies (such as those implemented through AppLocker) that allow execution of DHTML applications but forbid local installation of native applications. It's the same reason that early Wii homebrew (such as WiiCade.com) relied on Flash and DHTML instead of native applications, which Nintendo forbade amateurs from developing, until the Twilight Hack blew open native homebrew.
The Firefox installer is in the neighborhood of 40 MB. That's two and a half hours of tying up the phone line if you have v.90/v.92 dial-up, or a nonzero cost if your ISP charges per bit as many cellular and satellite ISPs do.
Seriously, whats next, will they just stop support plain HTTP because HTTP is far more likely to be abused.
They're heading in that direction. Service Workers are the new mechanism for a web application to continue to work during interruptions in the Internet connection, and browsers already forbid use of Service Workers delivered through HTTP unless they came from localhost.
But another difference has been repeated in previous articles about Perspectives, Convergence, WoSign, Let's Encrypt, and other means of working around the cost of avoiding MITM attacks on TLS. The difference between cleartext and low-grade TLS, such as HTTPS with a self-signed certificate or old versions of TLS or weak hash algorithms, is a difference between a true sense of insecurity and a false sense of security. With HTTP, you know what you're not getting, as the globe in the address bar represents everyone who can potentially intercept your communication.
By definition, anyone here is someone the NSA doesn't care about anyway, so who cares about encryption?
Without encryption, anyone can sniff your session cookie, clone it, and post Goatse as fahrbot-bot.
For production sites, you don't use the auto-generated cert.
Correct: you export a CSR from the auto-generated keypair and use that to buy a certificate. Normally, you'd export one server's auto-generated keypair, export a CSR, buy the certificate, and import it to the other servers. But if you're paranoid about never exporting a private key, you'll end up with a separate certificate on each server in your load-balancing cluster.
To keep our PCI compliance we have to switch away from TLS1.0 and our processors basically forced us this year. So we had to get around that in a number of ... less than perfect ways.
To this day I'm unaware of a valid technical justification for the above change. I keep hearing irrelevant excuses about implementation bugs and or solved problems having been well understood and fixed for years. There seems to be no new discovery that has served to justify abandoning TLS 1.0. SHA-1 is at least supported by a coherent understandable problem.
Any scheme to probe clients to determine if they support only SHA-1 I'm in favor of so long as sites doing so warn customers and recommend upgrades. There is no chance of this affecting upgraded clients refusing SHA-1 and simply cutting millions of people off has its own costs. Given there is no public evidence of a successful SHA-1 forgery and all actors with the resources to create one first likely completely have their way with multiple CAs anyway.
You have to update eventually... let the old things rot. Why do we even have to support the old junk anymore?
- Website owners configure allowable ciphers on their websites, which presumably the configure based on their user requirements.
- Browsers negotiate strongest supported configurable ciphers advertised by websites.
Why the hell do browser companies want to remove SHA1 support all together? Seriously, whats next, will they just stop support plain HTTP because HTTP is far more likely to be abused.
This really isn't about negotiation of weak ciphers it is about weaknesses in trust chain that allow third parties to insert fake certificates undetected. No matter what you negotiate based on a broken chain of trust the result is a lie.... this includes any possible attempt at "secure negotiation" as the fruits are based upon the lie of a valid trust chain.
Why, exactly, would it be a good thing to use some sort of janky hack to allow people to use encryption that we strongly suspect of being dangerously broken, or close to it?
Yes, it's unfortunate that there are people stuck on hardware or software that can't handle updated algorithms; but their ability to use encrypted communication is compromised by the fact that SHA1 is tottering, not by the fact that some servers might stop negotating connections using it. Is there some benefit I'm not understanding here to bodging something together so that antique browsers can enjoy a false sense of security?
Is the notion that SHA1 isn't "all that broken", and is good enough to keep uninteresting traffic safe? Or does Zuckerberg just not want to lose that comforting little 'lock' symbol for his 40 million poorest facebook chattels?
So, in other words, Slashdot is partially my fault?
#DeleteChrome
And when "whomever" amounts to the "poorest, most repressive, and most war-torn countries in the world," as the article mentions, what recourse does one have?
Ending the repression and the combat would seem to be one option.
Perhaps it's worth considering doing that?
The change in the PCI compliance was due to the reclassification of a vulnerability. To understand how this came about, you need to consider the following two vulnerabilities.
CVE-2011-3389 (BEAST attack)
CVE-2013-2566 (RC4 ciphers enabled)
CVE-2011-3389 has a CVSS v2 Base Score of 4.3.
Earlier this year, CVE-2013-2566 had a base score of 2.9.
Any vulnerability with a score higher than 4 is a PCI fail. As a result of this, PCI compliant TLS 1.0 servers were all using RC4 ciphers instead of CBC ciphers - pretty crappy given that BEAST was mitigated long ago and CBC ciphers were generally accepted as more secure than RC4.
So to get around that, someone wrote to the NIST to see if the score for CVE-2011-3389 could be reduced so that system admins could run PCI compliant TLS 1.0 servers without having to resort to the very risky RC4 ciphers. Some said, the NIST never changes CVSS scores so it was pointless, but the request was made.
And this is where it went wrong. Instead of reducing the score for CVE-2011-3389, they INCREASED the score for CVE-2013-2566. It now has a CVSS v2 Base Score of 4.3. :(
This decision by the NIST, essentially put the final nail in the coffin for PCI compliance using TLS 1.0. :(
You'd better have a monopoly on the product you are selling or the customer will just decide "the hell with that" and buy from another site that is easier.
If you see your would-be customers leaving for competing merchants that blatantly violate PCI DSS, report each noncompliant merchant to the company that handles its payment processing. When competing merchants start either turning away customers in the same way or losing their merchant accounts, watch upgrade conversions increase.
poorest, most repressive, and most war-torn countries in the world
Go cry to whomever is creating that problem for you, and if that amounts to you then keep it to yourself.
what recourse does one have?
Ending the repression and the combat
How would affected end users go about that, given the gross wealth inequality endemic in those parts of the world?
Two paragraphs dumbass.
The first paragraph refers to the worse kind of people, scammers and terrorist.
Second paragraph, relief agencies that are not counted as "the worse kind of people', nor are the people they are trying to help. The relief agencies that I'm talking about don't have the large budgets for non-essential stuff, like up to date computers. They have to rely on handed down computers. Most of these computers are really outdated, 200 MHz pentums or lower.
Supporting World Peace Through Nuclear Pacification
CVE-2011-3389 (BEAST attack)
As we all know this was worked around more than a decade ago and all browsers save an ancient Safari outlier are not vulnerable to it.
CVE-2013-2566 (RC4 ciphers enabled)
We all know that cipher suites can be turned on and off independent of TLS version.
CVE-2011-3389 has a CVSS v2 Base Score of 4.3.
Earlier this year, CVE-2013-2566 had a base score of 2.9.
Any vulnerability with a score higher than 4 is a PCI fail.
I would love for someone to provide a reference where in PCI a CVE scoring regime for PCI compliance is even mentioned.
Regardless these problems are not vulnerabilities when you turn off a broken cipher suite and implement workarounds having existed for more than a decade. Saying otherwise would be like adding up the CVE's for Windows or Linux and giving it a score higher than 4 zillion even though underlying issues had been addressed long ago.
As a result of this, PCI compliant TLS 1.0 servers were all using RC4 ciphers instead of CBC ciphers - pretty crappy given that BEAST was mitigated long ago and CBC ciphers were generally accepted as more secure than RC4.
I have vague memories of people trying this nonsense but it didn't last long.
And this is where it went wrong. Instead of reducing the score for CVE-2011-3389, they INCREASED the score for CVE-2013-2566. It now has a CVSS v2 Base Score of 4.3. :(
This decision by the NIST, essentially put the final nail in the coffin for PCI compliance using TLS 1.0. :(
Curse you NIST... or NASA or GEOINT or KGB or whoever for a completely broken chain of incoherent nonsense.
My personal opinion this is a CONSPIRACY.. more trivial work / check boxes for the Nessus button pushers to run while they abstract absurd amounts of cash from their victims.
As we all know this was worked around more than a decade ago and all browsers save an ancient Safari outlier are not vulnerable to it.
Yes, but due to the CVSS score, using CBC based ciphers in TLS 1.0 is a fail. Sure, the risks have been mitigated and they are good to use, but you can't if you want to be PCI compliant.
We all know that cipher suites can be turned on and off independent of TLS version.
Yes, but if you turn off the RC4 ciphers and turn off the CBC based ciphers in TLS 1.0, there are no TLS 1.0 browsers that have a compatible cipher. This results in TLS 1.0 browsers no longer working in such a configuration. Hence the problem here.
I would love for someone to provide a reference where in PCI a CVE scoring regime for PCI compliance is even mentioned.
Here you go - Page 22
"With a few exceptions (see the Compliance Determination—Overall and by Component section below for
details), any vulnerability with a CVSS base score of 4.0 or higher will result in a non-compliant scan, and
all such vulnerabilities must be remediated by the scan customer. "
Regardless these problems are not vulnerabilities when you turn off a broken cipher suite and implement workarounds having existed for more than a decade.
Sure, not vulnerabilities, but still a PCI fail due to the NIST CVSS scoring, which is the point here. (Bureaucracy)
I have vague memories of people trying this nonsense but it didn't last long.
Earlier this year when I was researching this, there were very many financial sites that used RC4 ciphers. They had no choice but to do this if they wanted to support TLS 1.0 browsers AND be PCI compliant.
Curse you NIST... or NASA or GEOINT or KGB or whoever for a completely broken chain of incoherent nonsense.
Indeed.
My personal opinion this is a CONSPIRACY.. more trivial work / check boxes for the Nessus button pushers to run while they abstract absurd amounts of cash from their victims.
Not so. I was there when this came about. In fact, I kinda seeded the notion that this had to be dealt with by fixing the CVSS scoring with the NIST. I was just frustrated with the problem and wanted to find a 'correct' fix. But it blew up as explained previously - damn you, NIST.
that don't support SHA-2 will be left without access to encrypted websites.
This is much ado about nothing. The devices that cannot support it are dead ended already, They are not safe to use, so it makes sense that very soon they won't even be allowed to be used with SSL websites, even if the Webmaster wanted them to work. All the SSL websites I manage are already using SHA-2 certificates Besides you DONT use an OS without SHA2 support and have zero issues today
Also, the SHA-1 certs are considered weak and unsuitable for secure usage at this point, even sites such as Amazon and BankOfAmerica are using SHA-2 certs.
I think all the major e-tailers have X509 certs with a SHA-2 signature at this point.
How does Facebook/Cloudflare fallback mechanism work?
I have saw a few explanation here about SHA1 cipher negotiation, but this is about certificate, not cipher.
Oh, good. I was worried somebody else was getting undue credit.
#DeleteChrome
Maybe it's time for me to become a field agent for the CIA. I could go get a job at their IT field office and say stuff like, "That Windows 10 update offer? Yeah, I'm going to need you to click the ACCEPT button on that. Yes, I'll hold."
"So long and thanks for all the fish."
"You must be great fun at parties."
Il n'y a pas de Planet B.