Can someone please explain why this encryption limitation is OS level and not application level? XP can't handle new encryption but why can't Firefox/Chrome on XP handle it? Why can't they include their own updated encryption code within their browser?
Firefox and Chrome can. But lots of people use the system's browser, just because they don't know how to install their own browser.
Also you have to consider that there are devices out there that include a browser, but no way to install your own software. Gaming consoles, phones, TVs etc. with included browsers, many of them with outdated technologies and with no way to update or install your own software.
They can and they do. Mozilla uses NSS, Chrome their own OpenSSL fork (BoringSSL). This only really affects IE and other applications which don't have to be actual browsers.
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
Yes. That would also be an option. We'll see what works best (read: with the least amount of work. We're not selling these devices any more, so effort spent in supporting them is basically wasted)
No need to guilt-trip me. Of course we're going to make sure the scanners keep working (as I said in my previous comment).
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.
I don't mean to guilt-trip you. I merely think that maintenance of provided solutions is what a responsible company should do. So in this case, personally, I think what you do is not wasted effort.
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.
> 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.
One solution is to use a proxy. I run a filtering proxy, and force all HTTP and HTTPS traffic through it. It can be upgraded easily since it uses the standard OpenSSL DLLs.
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.)
That's another very good idea I'm going to look into, though I'm a bit weary of dealing with writing and/or finding and compiling a proxy server for a version of Windows CE that's now 4 years out of support.
The article mentions this - "most" people are running the latest Firefix/Chrime browser or smartphone and will have been upgraded. The danger is in "developing countries" (sic) where we can see older operating systems, cracked versions of Windows with no upgrade path, dumbphones that do not do encryption and of course anyone in the office of personnel management.
There's also the bootstrapping problem. Let's say you want to get the latest browser for your phone/PC - how do you download it with your default browser?
Even if Firefox had a plain http site for legacy downloads - how could you trust the executable?
Technically, you could check the hash, no? Of course, you'd need a reliable source to give you the hash, so you could make sure you weren't given a fake hash of the fake download.
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.
Why is it bad? If they update browser, they can update OS component. And if they dropped support for OS, new browsers are unlikely to work in this OS anyway.
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.
Because it might be better if the browser would be updated even years after the support for XP has been dropped? At least update IE, or show people the Browserchoice Window with a message saying "IE is no longer supported, select another browser"
At CloudFlare, our solution to this problem for our customers is to automatically support SHA2 for modern browsers and fall back to SHA1 for legacy browsers that don't support SHA2. This is in place for most paying customers already. It will be complete for all paying customer by the end of the week.
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.
(A) A significant percentage of users with legacy browsers could upgrade (by installing Chrome or Firefox, instead of relying on a woefully out of date bundled browser). If much of the internet stops working for them, I imagine knowledge of how to get it working again will spread pretty quickly.
(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.
(A) If you've ever traveled across rural Africa or rural China or rural India and seen how many people access the Internet over original Android (if they're lucky) or Candy Bar Phones (if they're not) you'd realize the folly of your argument.
(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.
You may not even need to travel to the third world. Just wait until all those "smart" cars, refrigerators, etc. with "secure" (i.e. not user tamperable) update mechanisms come out of warranty.
Amusingly, these users may not be able to download modern browsers from the official websites, which will of course be only available over TLS for obvious security reasons ...
Not in any way we've been able to think of — and we've spent a lot of time thinking about this and running it by the crypto community. But, if someone can demonstrate such an attack and we can't fix it technically, then we will drop support for the SHA1 fallback. And, on a customer-by-customer basis, we'll allow customer to turn off fallback if they're worried about a theoretical, if undemonstrated, attack.
No mitigation is required. Part of the data signed by the server certificate in the handshake is the entire ClientHello message. If a MitM attacker did a downgrade, they would have to change the ClientHello, and then the client would notice that what the server signed does not match what they sent.
Are you looking at anything beyond the SignatureAlgorithms TLS extension? That is the obvious solution, but I know there are a few browsers that support sha256 certificates that don't send that extension.
Yes. It's above my pay grade to walk through what we're doing to fingerprint TLS connections. However, we will provide a thorough blog on what we're doing and open source the algorithm we're using.
"above my pay grade" is an odd phrase to use considering that your profile says you're the CEO, but I'm guessing you mainly mean you're not familiar with the details?
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.
Yes, I was being a bit flip. But only a bit. We strive to be a company where engineering drives our priorities. While, a long, long time ago, I wrote a tiny bit of the code that became CloudFlare, there's no way I'd be trusted to do that today. There are engineers on our team whose salaries are far higher than mine. And, in this case, while I've been briefed on what we're doing, I don't feel comfortable enough with the details to comment on them. Thankfully, the people who are should be getting to work in London soon and I've asked that they watch this thread.
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.
I have somewhat mixed feelings regarding SHA1 support. On the one hand, it is useful in some cases to support legacy clients that "can't" upgrade. On the other hand, I don't feel too bad about cutting off clients that are basically a blight on the internet - many of these applications have numerous security issues beyond weak crypto.
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.
We actually look at the sigalgs and the cipher suites and have code that understands the behavior of different browsers. For example, Chrome on Windows XP sends ECDSA/SHA256 in its sigalgs, but doesn't actually support ECDSA.
I figured you'd look at the cipher suites and have a list of fingerprints for ones that needed special handling. I'm pretty surprised that WinXP Chrome falsely claims support for ECDSA... Does the switch to BoringSSL fix that, or no because Chrome's relying on the built in Windows certificate store/validation?
Since you already have the capability to do something different for SHA-256-intolerant browsers, I suggest you inject (this year with permission from your customers) banners informing the users of these browsers to switch to SHA-256-compatible browsers (Firefox on XP and Opera Mini on mobile) while they still can. It's not like the users "cannot" upgrade. They don't know how.
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.
1. Right. I suggested they probably should (with permission) to change the content.
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.
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.
The Cloudflare ancestor comment raised the concern about certain countries--not enterprise. The CA/B forum post is relevant regarding the downsides of exceptions even if the thread there focuses on enterprise issues.
They've had plenty of warning. We've already seen that SHA1 could soon be cracked by relatively cheap computing power. Also, this is essentially saying that 3rd party companies should continue to support Windows XP, which is silly, considering even Microsoft stopped (officially) supporting it a while ago.
Does anyone have any sense of who or what groups would benefit from dropping $75k on developing an attack that might not even return any results? I've heard a bit about the underground Russian scene. Those guys are smart and their leaders are motivated and loaded.
Nobody seems to have yet picked up on tls 1.0 becoming obsolete next June for PCI purposes - about 20% of Web users can't do better without an OS upgrade - IE on xp, older android, etc. We've been measuring this for about a year and it was 24% this time last year.
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.
Chrome is already dropping XP support in just a month or two. While Firefox is not going to change in the short term, its really not a great idea to stay on XP if you have a way out.
Sadly, XP users who should be installing Firefox or Linux or Nokia users who should be installing Opera Mini don't read tech news. Is anyone trying to inform them ahead of time?
Worse than that. As the migration to SHA2 is forced, even if they want to upgrade they won't be able to because they won't be able to securely download executables for modern browsers.
No, it's not SHA2 encryption. SHA2 is a hashing function, meaning it's one way. Encryption is two way or else it wouldn't work. People often confuse the two but they are quite different.
XP is 14 years old, I don't care what bullshit excuses you have. It's your problem now and the world is not going to wait for you. Sick and tired of people offloading responsibility to the rest of the world because they can't be bothered to spend the time and resources to catch up with time.
Windows XP actually supports it, you just need SP3 installed (released in 2008). Android 2.2x (and below) is the biggest group of incompatible users, many XP users will be fine.
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.
It's a damn shame that X.509v3 doesn't support multiple signatures on a single certificate. That would really ease the transition to new signing algorithms. I can't really fault the CAs or browser developers here because X.509 doesn't facilitate forwards compatibility.
Everyone is talking about personal computers and mobile devices. Not mentioned: the IoT movement with devices in the field with minimal capabilities and no path for upgrade.
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
65 comments
[ 3.4 ms ] story [ 137 ms ] threadThis 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
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.
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.)
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.
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.
(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.
Doesn't this expose users to downgrade attack?
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.
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.
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
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.
Catch-22
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.
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