As sites move to SHA2 encryption, millions face HTTPS lock-out
zdnet.com
zdnet.com
For free customers using our Universal SSL solution, only modern browsers are supported so it has only used SHA2 certificates since it launched over a year ago.
The danger is that after December 31, 2015 we may no longer be able to get SHA1 certificates for new customers because CAs have been told by browser vendors to no longer issue them. While that won't cause a problem for modern browsers, for legacy browsers that can't be upgraded it will mean they will not be able to access the encrypted web. Unfortunately, that disproportionately affects regions of the world where censorship risk is high. In Iran, China, and parts of Africa with more restrictive governments, legacy browser traffic is as high as 30%.
If providers like CloudFlare who can safely support SHA1 certificates only for legacy browsers, while supporting SHA2 for modern browsers, cannot continue to get SHA1 certificates then we risk cutting off a substantial portion of the most vulnerable Internet users from the encrypted web. That is a bad outcome.
We will be talking more about this on our blog in the coming weeks and plan to open source the TLS handshake fingerprinting logic we're using to identify what browsers only support SHA1. I'm hopeful that the browser vendors and CAs will do the appropriate thing by requiring modern browsers to only support modern hashing algorithms but allow providers like us to continue to support the best available cryptography for those users who cannot upgrade to the latest browser tech.
Doesn't this expose users to downgrade attack?
Also, if you successfully lobbied an exception for you to keep using SHA-1, less savvy deployers of TLS would get an opportunity to mix SHA-1 with modern browsers or to non-browser clients--weakening security for everyone. (See https://cabforum.org/pipermail/public/2015-October/006100.ht... )
1. They're providing different valid signature, not changing the content of the communication itself.
2. Injecting anything into a valid response is a terrible idea. Broken cache, potentially breaking scripts relying on dom layout, messing up file fingerprints, etc. etc.
3. "It's not like the users "cannot" upgrade. They don't know how." No, lots of people cannot upgrade. Corporate policies, hardware requirements, weird device backwards compatibility, and many other reasons may prevent you from upgrading a system.
4. "less savvy deployers of TLS would get an opportunity to mix SHA-1 with modern browsers" They'll be marked as insecure very soon - this is a pretty good reason not to serve sha1 cert to a modern browser.
2. The cache is a red herring. It wouldn't matter on the Cloudflare side if done on the edge. It wouldn't matter on the client, because the client would only see either the SHA-1 view or the SHA-2 view. Again with permission of their customers. If you have a SHA-2-intolerant browser, it's not checking for fingerprints. Chances are that scripts already break in legacy browsers.
3. The concern here isn't about corporate policies. A policy that says you have to stay on IE on an obsolete service pack of an obsolete system gets no sympathy. The concern here people in Africa/China etc. who can't affort to pay for an upgrade. Firefox, Xubuntu, Opera Mini, etc. are free.
4. Did you read the CA/B Forum email I linked to?
That's a completely different argument then. There's a lot of users in both categories. I just disagree with blanket "It's not like users "cannot" upgrade".
I did read the CA/B post which mostly deals with... enterprise internal policies and security relaxation. So what are we talking about here now? Poor 3rd world countries that can't afford upgrades, or enterprises? Non-enterprise users don't have an intranet zone.
Re. cloudflare. No, I still disagree. There's a number of reasons why it's important to get exactly what the server sends. Even with permission from the user MITM-ing traffic to inject banners is a terrible idea that's likely to break things.
(B) It seems incredibly difficult (impossible?) to support graceful downgrade to older insecure approaches to TLS without also introducing the opportunity for a downgrade attack.
Many of the TLS attacks we've witnessed over the last few years seem to be the direct result of bending over backwards to maintain backwards compatibility. I'm unconvinced it can be done safely.
(B) If someone can find a vulnerability to our implementation that we cannot fix then we'll drop support for SHA1 fallback. We'll also allow customers to turn off SHA1 fallback if they'd prefer. But that should be the choice of a site on a site-by-site basis, not imposed by the browser vendors.
I'm pretty sure I know exactly what you're doing, but I'm very interested to see how much of the secret sauce you'll share.
PS - I have no problem sharing the complete "secret sauce" as the biggest risk here to us is not competition but that CAs after December 31, 2015 won't be allowed to issue SHA1 certificates anymore. The more organizations that can responsibly support SHA1 fallback, regardless of whether they're CloudFlare customers, the more likely it is we can convince the CA/B forum to allow the extension of the issuance of SHA1 certs to responsible parties.
As far as the CAs and browsers go, I would expect them to push back based on concern of not being able to enforce "you must support SHA256 and can only use SHA1 as a fallback". The browser vendors have the threat of scary SSL error screens, but people often click through those anyway, and habituating people to doing so is bad. Exceptions could be disabled, but that might just push more people to legacy browsers because they "work".
I think this is gonna end up being one of those "pick the least bad solution" kind of things.
This mess also affects me greatly because I have around 2k Windows Mobile 6 based barcode scanners around which use SSL. Their HTTP client is just using the OS provided APIs.
Now we're going to have to use a self-signed cert and update the application to accept that pinned cert
Courtesy of that, this comment has been posted to HN with TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, from a client that only supports TLS 1.0 and nothing beyond RC4-MD5. (It's actually configured to ask for ECDHE-RSA-AES256-GCM-SHA384 first, which is probably overkill, so I don't see many servers that choose it.)
However, it's also clear that we'll have to take the route that requires the least amount of effort for the fix as any time spent on these old scanners is time we can't spend on the current android based scanners that provide a vastly superior user experience.
It's not wasted effort because (I hope that) customers will remember whether the provided solution broke down and vendor just walked away, or whether your company took responsibility of architectural decisions.
sure. But at some point you have to make a cut off. Customers can't expect a solution they bought once to work for all eternity. Otherwise we'd all still be supporting IE5 on Windows 98 these days.
At some point, the time invested in keeping the old stuff running cuts too much into the time available to move the current stuff forward.
If all you do is spending time to patch up the old solution, you open yourself to be overtaken by competitors that either don't care about their old infrastructure, or by competitors that just entered the market without any prior customers to care about.
So really, keeping old stuff working (for some reasonable amount of time) is the ethical thing to do and certainly goes a long way to keep customers happy, at some point, you have to move forward or you will not be able to gain new customers, or worse, your old customers jump to a competitor that has the new, shiny thing and you end up maintaining a dwindling amount of legacy installations forever until you go out of business.
This is why I think spending time on maintaining outdated, 10 year old solutions is wasting time compared to maintaining the new and greatly improved thing.
Again: Despite these scanners being 10 years old now, we will do the effort required, but I still will try to do it the easiest way possible as every minute spent on this is a minute not spent on improving the non-outdated solution.
Even if Firefox had a plain http site for legacy downloads - how could you trust the executable?
So, you'd lookup the hash on a secure computer and then test the download after you insecurely downloaded it.
Of course, this is more than a general consumer would know or care to bother with.
It's not the case for 3-rd party browsers, of course, but IE is an integral part of Windows. So it makes sense to avoid crypto duplication.
And if they dropped support for OS, new
browsers are unlikely to work in this OS anyway.
Can't see that percentage dropping all that much before then, and clients won't be blaming users' poor practices or the pci council - it'll be the fault of Web developers, everywhere.
20% of Web users can't do better without an
OS upgrade - IE on xp
Catch-22
Older version of devices like TI's CC3200 (which appears to support SHA2 in hardware at least) will be forced offline without an upgrade (and in many cases I assume SW implementation of missing HW algos)
It's ironic: device developers tried to be forward looking with TLS security only to stumble over it later. I'm sure the subset of decisions makers that are clueless will blame security for crippling their systems. Now security is evil to the ignorant.
tl;dr; Plan for upgradability with embedded hardware products
Even I use Windows XP sp3 (and firefox/chrome anyway, not native IE)
No idea what percent of Android 2 users are out there but even I dumped my last 2.2 phone recently - kitkat 4 is so much better
0.2%. Don't know if locking them out is really a problem.
just like you still see IE6/7 user agents sometimes
however the millions of vulnerable kitkat install over the next decade is alarming
And before someone says "Android 2.2 users can just install custom ROMs!!!" keep in mind that a lot of unbranded or no-name handsets exist in other parts of the world, without a big enough community to create and maintain customs ROMs.
A lot of devices are legitimately stuck on 2.2 or 2.1.