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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
