FREAK show: Apple and Android SSL WIDE OPEN to snoopers Security researchers are warning of a flaw in OpenSSL and Apple's SecureTransport – a hangover from the days when the US government was twitchy about the spread of cryptography. It's a flaw that allows an attacker to decrypt your login cookies, and other sensitive information, from your HTTPS connections if you use a …
The list of how to use items has something along the lines of: convince to use crap key, factor key, then can inject what they want into the stream. Now, given we are also told that to factor the key would require about $100 of processing on AWS would I be right in suggesting this is more of a TLA flaw or highly targeted spear-fishing exercise toolkit rather than something your average pleb should fear? i.e. for the man on the street it is more of a theoretical exercise than a reality if we ignore for a moment those special folks at the NSA and GCHQ?
Accoording to Matthew Green it takes a lot of time to generate the keys. So a server will reuse the key; specifically, "Apache mod_ssl by default will generate a single export-grade RSA key when the server starts up, and will simply re-use that key for the lifetime of that server....[which means] you can obtain that RSA key once, factor it, and break every session you can get your 'man in the middle' mitts on until the server goes down."
This point should've been in the article.
@Brewster: Thanks, that's an important missing point.
On my previous comment and responses, that $100 is easy to come by is irrelevant as that implies a targeted attack on the client end or else you need to be able to afford to MITM however many clients to pursue the necessary pot of gold.
The fact that this missing (in the article) information states you can target a server which is using a single (per uptime) key gives rise to a much better use of a $100 once-off outlay and opens the attack up to all and sundry.
HTC One (M8) with Android 5.0.1 (latest versions of everything)
Built in HTC Internet app (7.0...): Vulnerable
Google Chrome (40.0.2214...): Vulnerable
Opera (27.0.1698...): Vulnerable
Maybe it's just an Android thing and I'll have to wait until I get another OS upgrade from HTC in a year...
This is an issue with telcos locking down phones that they claim they're selling to you. You should never buy a locked phone. You will regret it in 6 months when you've hit a major bug and the telco offers to fix it with a $250 phone swap.
BTW, Apple stops providing security patches to older models too and offers no workaround other than switching to Linux or buying a new computer that isn't actually any faster.
About a year ago Apple released a security update for iOS 6 to version 6.1.6 - the latest version a 3gs can run which was ALMOST FIVE YEARS OLD at the time. I would not be shocked if a version 6.1.7 pops out in a few weeks, though maybe supporting the 3gs almost six years after its release is asking a bit much.
The situation with security patches for iOS is not even remotely comparable to Android. Try again.
"Hopefully attacks like this may make him think...
On evidence so far the minimum required to achieve a measurable amount of sustained, independent thought would be major surgery to add the relevant grey matter. To make the output usable though is probably beyond medical science.
One thing that hit me was this "... and the client either offers an RSA_EXPORT suite or is using a version of OpenSSL that is vulnerable to CVE-2015-0204"
Basically, one of the decisions taken by OpenSSL developers was (and still is) "do not remove compatibility features", thus we can still see bits of code specifically for platforms such as VMS or Win16 - even though OpenSSL has not been tested on those for a very, very long time. It also implements full support for weak encryption such as RSA_EXPORT. Hilariously OpenSSL even implements certificate check to fail the connection if stronger encryption than 512bit was employed on RSA_EXPORT session (look for SSL_alert_type_string).
Why do I point it out? Because vulnerability to degrade connection to insecure RSA_EXPORT would not happen, if OpenSSL did not keep such insecure implementation in the first place. But of course, it would go against philosophy of key developers. Which is why alternative libraries such as LibreSSL are so important.
I use it all the time to check for exactly this kind of stuff:
openssl s_client -connect www.my.site.with.ssl.com:443 -cipher EXPORT
I've been checking for both this and TDES usage since 2011. I've also made a point of disabling EXPORT, RC4 and TDES ciphers on whatever service I'm configuring from scratch. This is something that everyone should know about, but seems to be noticed only when someone discloses it.
I'd leave EXPORT support on OpenSSL for testing purposes only, but remove it from the "can downgrade to this cipher" list.
The fun fact about this is that it's the US Government's fault, and maybe the NSA's fault as well. The 90s had a lot of criticism on the ban on strong crypto export, and we all knew that was going to come back to bite 'em down the road.
It's trivial to exclude the EXPORT suites in the cipher-suite list when using OpenSSL in an application, and trivial to build OpenSSL without support for them.
While OpenSSL shouldn't be vulnerable to MITM downgrade attacks like CVE-2015-0204 (in which the client accepts the short temporary key even though it didn't include an EXPORT cipher suite in its ClientHello), there's little excuse for public servers that accept EXPORT suites by default today. That's either bad programming or bad administration.
Certainly there's a strong argument to be made that OpenSSL shouldn't include the EXP ciphers in its DEFAULT list; but developers using OpenSSL should at least understand how to set the cipher-suite list and set it to at least "DEFAULT:!EXP" by default. (Note that the OpenSSL developers have announced plans to remove various suites from DEFAULT in the next year or so, to some controversy.)
OpenSSL, out of the box, is not suitable for use by developers and administrators who don't want to be bothered learning anything about SSL/TLS. Those people shoud purchase a commercial solution and pay someone to walk them through it, or use some higher-level package that takes care of the gritty details. Blaming OpenSSL because people can't be bothered to learn how to use the tools they pick up is unfair.
OpenSSL, out of the box, is not suitable for use by developers and administrators who don't want to be bothered learning anything about SSL/TLS.
Pretty much any crypto API is not suitable for use by anyone who hasn't at least read something about SSL/TLS. I'm really surprised about the amount of devs, webmasters and sysadmins that had no idea about the existance of EXPORT ciphers at all. This is something they should know because a lot of them actually worked with the "international browser" versions from the late 90's which had the stupid 40-bit restriction hobbling SSL.
There's also a very high amount of developers who use self-signed certs in production enviroments. Another good bunch that outright disable SSL certificate validation to get their stuff to work, basically opening up their security infrastructure to MITM attacks within the organizational network. You've probably noticed that this sounds a lot like how SuperFish does SSL ... well, this is why those devs thought it was normal. They're used to doing this.
Oh well, at least some security-related products will have some kind of FIPS mode available. It's probably worth flipping that switch on as it will disable all EXPORT and LOW ciphers by default, including 3DES which is probably bound to be cracked in the near future.
Basically this tells us that both Apple and Google phones are unsafe by design, at least if unsafe is minimally defined as failing to provide reliable protection by enforcing current encryption standards. At the very least their devices could provide a software switch to require higher encryption than we had in the 90's. As others point out, yes, this is a server side problem. But there are lots of other server side problems we expect clients to deal with effectively.
What really needs to happen is for both Apple and Google to switch over to LibreSSL and NSS, supporting both on their devices and letting the user decide which to implement. Of course there are two problems with that: (a) Google has no way to update most of the devices sold under the Android name, even if they were so inclined, having traded market share for a hands-off approach to maintenance; and (b) Apple has resisted allowing competing standards on its phones (e.g. it will not allow NSS-enabled Mozilla branded Firefox or Google's own webKit, v8 or other features to be implemented on its platform).
The bottom line is that none of these devices as currently shipped are safe, and they should be used with great caution. Most of us below the exec level don't have to worry about proprietary company info being compromised, but our own personal banking and health care transactions are another thing. You really shouldn't do your banking or log on to your health care account via a mobile. Ever. Same is true for anything involving a credit card, like ordering merchandise from Amazon or streaming video from Netflix. Go to a more secure, and updated, computer for that. If you have credit cards linked to your phone account, or apps from 3rd parties that are, remove them (sorry, yes that means no more paid apps). This won't entirely eliminate the possibility of someone using your phone to steal your identity or your money, but it will reduce it dramatically.
Maybe if enough people did this the economics of lax security on phones would shift and give mobile manufacturers the incentive to do something about the problem. Until then at least you can save yourself, albeit at the cost of some inconvenience.
Amazing how many commentards log into a web site that says "you're vulnerable" and believe it.
This article refers to report that conflates two very different but slightly related vulnerabilities that most here would appear not to have a clue about.
Yes, some browsers are susceptible to CVE-2015-0204, but that flaw actually just means that if you're connecting to a server that decides to degrade the temporary key to export grade then you will not know about it. This is a server problem and is not possible with a man-in-the-middle attack unless your browser's root keys are also compromised. The only issue with the browser is that it continues without telling you.
However, browsers still supporting export grade keys when negotiating security is a big problem and it would be nice to have some idea of how big. Unfortunately dumb sites that conflate the two problems are worse than useless.
I wouldn't see this as a minor flaw as long as the browsers support it. Yes, if the server doesn't accept EXPORT keys, it's a non-issue. But at the time of writing, 2 out of 4 banks I've tested are vulnerable to this. As long as these sites remain unpatched, this vuln will remain serious.
Don't browse much from my Android smartphone but here's what I discovered:
Standard KitKat Android browser: FreakAttack FAIL!
Chrome Android browser: FreakAttack FAIL!
Opera Mini, FreakAttack, you can't get me
On the Windows 8.1 laptop:
Chrome FreakAttack, you can't get me,
FF FreakAttack, you can't get me
IE 11 Enhanced Security Configuration, can't tell, can't see site warning banner
IE 11 no Enhanced Security Configuration, dunno, ESC is set by group policy. Can't be bothered to remove it to see, but will give IE 11 the benefit of the doubt.
In any case, I won't use IE again until it actually works as a browser. Still waiting for Spartan, which may or may not disappoint.
I do not and will not perform credit card transactions from my mobe ever.
It's scary enough using it at the local Super Market.
So keep panicking, and carry on.
Follow the link to freakattack.com and you will learn that the report on FREAK is maintained by a team which can be contacted via zmap-team@umich.edu.
Later in the report there is a list of the "websites in the Alexa Top 10K [that] support RSA Export Suites". In that list is Alexa site #1662 which is ... yep, umich.edu.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
