BREAKING NEWS
ArsTechnica is reporting that a new / old attack vector haunts mobile phones due to a 20 year old export regulation.
Security experts have discovered a potentially catastrophic flaw that for more than a decade has made it possible for attackers to decrypt HTTPS-protected traffic passing between Android or Apple devices and hundreds of thousands or millions of websites, including AmericanExpress.com, Bloomberg.com, NSA.gov, and FBI.gov.
The problem is caused by another encryption down-grade request that most phones honor. Web sites capable of using the weaker standards can can be tricked into downgrading the encryption protocol, and the phones will dutifully follow.
In recent days, a scan of more than 14 million websites that support the secure sockets layer or transport layer security protocols found that more than 36 percent of them were vulnerable to the decryption attacks. The exploit takes about seven hours to carry out and costs as little as $100 per site. The so-called FREAK attack—short for Factoring attack on RSA-EXPORT Keys—is possible when an end user with a vulnerable device—currently known to include Android smartphones, iPhones, and Macs running Apple's OS X operating system—connects to a vulnerable HTTPS-protected website. Vulnerable sites are those configured to use a weak cipher that many had presumed had been retired long ago. At the time this post was being prepared, most Windows and Linux end-user devices were not believed to be affected.
At the time of this posting, the security flaw has only been known for several hours. I recommend everyone read the ARS article, which explains it better than I can.
You will see many more stories on this in coming days. It wasn't the only vulnerability released today.
Edit: Added a link to the the National Vulnerability Database post per request. ~mrcoolbp
(Score: 2) by martyb on Wednesday March 04 2015, @04:02AM
Hmmm, I saw no mention in TFS about Blackberry... I wonder if they are affected, too? Though they have lost some of their popularity, they were BIG in the gov't and military arena.
Wit is intellect, dancing.
(Score: 4, Informative) by c0lo on Wednesday March 04 2015, @04:26AM
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 4, Insightful) by Nerdfest on Wednesday March 04 2015, @11:10AM
Oddly? If there's an exploit, IE is generally all over it.
(Score: 2) by c0lo on Wednesday March 04 2015, @12:11PM
Yes, but when you take it together with
it becomes odd indeed. Look like heaps of Windows "end-user devices" may be safe, but not the "IE11 in the Windows Technical Preview". Something is fishy.
Anyway
but maybe it's better to abstain browsing using Mrs. Robert's WiFi [xkcd.com] (anyway, it never been a good idea at any time).
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 3, Insightful) by davester666 on Wednesday March 04 2015, @06:53AM
It's not a mobile-specific issue. It's an SSL issue. They just put Apple and Android in the title because they are hit-whores.
(Score: 3, Informative) by frojack on Wednesday March 04 2015, @07:17AM
Not completely true.
Most desktop browsers do not support the older weaker standard, and haven't for a several years. (Although IE 11 is said to be vulnerable as well, but then Microsoft always been week encryption friendly.
At the time this post was being prepared, most Windows and Linux end-user devices were not believed to be affected.
Many android phone still run the android standard browser (the webkit one, Chrome), as do the iPhone and OSx on the mac. So I suspect that it is the browser code from that linage (which traces its legacy back to Konqueror in Linux) which contains the old 512-bit encryption key tech.
No, you are mistaken. I've always had this sig.
(Score: 2) by frojack on Wednesday March 04 2015, @08:01AM
Oh, and Google just released and update to Version 40.0.2214.115 m This was on windows.
Chrome for linux also updated with the last two hours.
No, you are mistaken. I've always had this sig.
(Score: 2) by sudo rm -rf on Wednesday March 04 2015, @10:35AM
On my Win7, mine just updated to V 41.0.2272.76 m, the Version you mentioned was installed before (at least since Feb. 17th). Though maybe this is a localization thing (me living in europe)
(Score: 2) by frojack on Thursday March 05 2015, @04:40AM
Yup, mine too Version 41.0.2272.76 m.
No, you are mistaken. I've always had this sig.
(Score: 2) by Hairyfeet on Wednesday March 04 2015, @08:13AM
I guess all those millions of Android users Google kicked to the curb are EXTRA fucked now, huh? I've got Dolphin loaded on all mine so hopefully I'm safe but how many just run the default browser?
As for IE every time MSFT drops a feature from IE the corporate users pitch a shitfit, just look at the "Save IE6 petition" so they are damned if they do, damned if they don't. How much you wanna bet that is why they are coming out with Spartan? I really wouldn't be surprised if they keep IE 8-11 on some kind of life support as an optional download for the corporate customers while the home users will be given the modern and up to date Spartan.
At least it won't affect my customers, after the IE 6 debacle I moved everybody onto Gecko and Chromium based browsers with ABP and auto updates enabled, whether IE is a good browser or not anymore really doesn't matter IMHO, its just got too big a bullseye painted on it to be used by my customers.
ACs are never seen so don't bother. Always ready to show SJWs for the racists they are.
(Score: 4, Informative) by kaszz on Wednesday March 04 2015, @09:13AM
Blackberry 10.3.1.2267 - vulnerable
OpenSSL 0.9.8zc - vulnerable
OpenSSL 1.0.0a-o - vulnerable
OpenSSL 1.0.1a-j - vulnerable
Chrome 40.0.2214.115 m - fixed?
Apple iOS - fix next week?
Apple OS X - fix next week?
Microsoft IE11 Windows technical preview - vulnerable
Firefox - not affected?
It would be really useful to know what's the latest version is that is vurnable. And of course which is the first one to be immune.
Convinience links:
NIST/NVD vulnerability summary for CVE-2015-0204 [nist.gov]
More technical detail on how the attack works [cryptographyengineering.com]
New FREAK Attack Threatens Many SSL Clients [threatpost.com]
Attack of the week: FREAK (or 'factoring the NSA for fun and profit') [cryptographyengineering.com]
LibreSSL [libressl.org] (OpenSSL 2014 fork)
56-bit Export cipher suites for TLS [ietf.org]
Tracking the FREAK Attack [freakattack.com]
(Score: 0) by Anonymous Coward on Wednesday March 04 2015, @04:46AM
get ready for the day that quantum computers utterly break all RSA
(Score: 5, Insightful) by NotSanguine on Wednesday March 04 2015, @04:48AM
In future, please include a link to the the NIST/NVD CVE posting [nist.gov] in TFS.
It's more useful than any news site article and provides exactly the information (including exploit, if available) needed to assess the vulnerability of one's systems.
Thanks!
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 2) by mrcoolbp on Wednesday March 04 2015, @05:24AM
Added.
(Score:1^½, Radical)
(Score: 2) by NotSanguine on Wednesday March 04 2015, @05:54AM
Thank you kindly, sir!
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 2) by GungnirSniper on Wednesday March 04 2015, @04:59AM
I motion that we remove BREAKING from the headline when the submission is posted. Otherwise we look silly when other places have it first.
Tips for better submissions to help our site grow. [soylentnews.org]
(Score: 5, Funny) by Anonymous Coward on Wednesday March 04 2015, @05:48AM
You misunderstand. This is news about breaking encryption.
(Score: -1, Redundant) by Anonymous Coward on Wednesday March 04 2015, @10:51AM
But this is about BREAKING encryption!
(Score: 3, Interesting) by albert on Wednesday March 04 2015, @05:06AM
Pretty much any government can issue a certificate for every web site. For example, China's military can issue a soylentnews.org certificate and your browser will trust it. They can also mess with routing to obtain all your packets (been done by China and Pakistan) and they can usually mess with DNS.
Why worry about weak crypto? This is like leaving your door wide open and then complaining that your window locks can snap.
(Score: 4, Interesting) by c0lo on Wednesday March 04 2015, @06:16AM
Can you please stick to using car analogies?
Because this one... maybe I didn't get it quite right, but: China can issue a fake certificate that will be trusted by your browser, but the guy at your favourite Free-WiFi coffee-shop (if it's starbucks, shame on you) can't.
But what that guy can do is to fuzz your connection, force the site you are visiting to drop to a 512 key, crack it and use it afterwards to decrypt the traffic of any device that accepts a fallback on the same key (eavesdropping and possibly intercepting more juicy info, MiTM, let your imagination run wild, it's a pants-down you wouldn't expect).
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0) by Anonymous Coward on Wednesday March 04 2015, @07:55AM
That was a horrible car analogy. Maybe you forgot to preface it with "While you're sitting in your car getting free WiFi from your favorite free-WiFi coffee shop ..."
(Score: 2) by stormwyrm on Wednesday March 04 2015, @07:55AM
Governments aren't the only possible threat to your security. There are the garden-variety computer criminals too, and they can use this sort of technique just as effectively. Someone running a malicious public WiFi access point could use it for instance.
Certificate pinning would, by the way, protect against a phony certificate like what you describe if you had already visited the secure site before, but it won't protect you against this attack because you'll still be seeing the genuine site certificate, although it is authenticated and encrypted by a 512-bit RSA key which is as good as toilet paper against today's computing power. This article [cryptographyengineering.com] seems to give more technical detail on how the attack works.
Numquam ponenda est pluralitas sine necessitate.
(Score: 2) by kaszz on Wednesday March 04 2015, @08:29AM
How long RSA key do you think is proper?
(Score: 2) by stormwyrm on Wednesday March 04 2015, @09:44AM
Against today's computing power and mathematical techniques, at least 2048 bits, 3072 is even better but still reasonably practical. This article:
http://en.wikipedia.org/wiki/Key_length [wikipedia.org]
Discusses the issue at length.
Numquam ponenda est pluralitas sine necessitate.
(Score: 2) by kaszz on Wednesday March 04 2015, @10:03AM
I just noted the magnitude of different bit lengths for RSA vs say AES.
(Score: 3, Informative) by Leebert on Wednesday March 04 2015, @11:57AM
RSA is asymmetric, AES is symmetric. Asymmetric keys have a significantly lower "bit strength" than their key length. In the case of RSA, you need a 3072-bit key to provide the same effective level of protection as a 128-bit AES key. You can see a table of comparable bit strengths in NIST Special Publication 800-57 Part 1 [nist.gov] (Table 2 on pg. 64).
The specific details of why are mostly above my head, but basically it's because asymmetric keys are two related keys, one which is known to the attacker. The relation allows the attacker to make some inferences about the private key.
(Score: 2) by MichaelDavidCrawford on Wednesday March 04 2015, @05:42AM
I expect what you really mean to say is that WebKit browsers are vulnerable; Mobile Safari on iOS, and Chrome on Android both use WebKit.
I haven't read TFA, but the report that "Linux" is not vulnerable probably means that Firefox isn't vulnerable, as it does not use WebKit. There are other browsers for "Linux", but I don't know which use WebKit and which don't.
I understand that Firefox is available for Android; if you use Android Firefox, are you vulnerable? If not then at least Android users have a workaround.
The problem might not be in the browser though, maybe it's in OpenSSL or some other library that Chrome and Mobile Safari depend on.
Yes I Have No Bananas. [gofundme.com]
(Score: 5, Informative) by NotSanguine on Wednesday March 04 2015, @06:05AM
The problem might not be in the browser though, maybe it's in OpenSSL or some other library that Chrome and Mobile Safari depend on.
It's not. It's OpenSSL. According to CVE 2015-0204 [nist.gov] the following versions are vulnerable:
openssl:0.9.8zc and previous versions
openssl:1.0.0[a|b|c|d|e|f|g|h|i|j|k|l|m|n|o]
openssl:1.0.1[a|b|c|d|e|f|g|h|i|j]
I tried to just blockquote the list from the CVE, but got smacked with the "compression filter" so I condensed it.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 1, Informative) by Anonymous Coward on Wednesday March 04 2015, @08:13AM
Firefox uses the Network Security Services (NSS) library to do SSL/TLS, which isn't impacted by this bug.
(Score: 2) by frojack on Wednesday March 04 2015, @07:48AM
I thought Google dropped webkit for blink.
http://www.wired.com/2013/04/blink/ [wired.com]
No, you are mistaken. I've always had this sig.
(Score: 3, Informative) by Hartree on Wednesday March 04 2015, @05:56AM
But, there were a number of people back in the 90s who said that mandating weaker export systems might well come back to bite.
(Score: 1, Interesting) by Anonymous Coward on Wednesday March 04 2015, @06:50AM
Its not like they were anticipating bugs like this.
The argument against weakened crypto for export was that it was weakened crypto.
(Score: 3, Insightful) by Hartree on Wednesday March 04 2015, @03:12PM
Not this particular bug, of course. That said, one part of the argument was that by putting out weakened versions of popular software, you would tend to drive security to a lowest common denominator at least partially to be compatible with the weakened versions. Also, it would tend to lead to the very human trait of thinking that if some transactions were encrypted with weaker crypto, then it should be "good enough" for all. Further, you couldn't guarantee that the weakened versions wouldn't be used to encrypt things that should be more strongly encrypted.
And, what do we have here? Weakened crypto being used for compatibility reasons leading to a leak of information about the nature of keying material used for more strongly encrypted material.
(Score: 2) by sjames on Thursday March 05 2015, @12:21AM
Not exactly like this, but related. Many decent crypto systems will choke and die if you even attempt to create or use a too-short key. The severity of this problem would be considerably reduced is the choke and die threshold was 1024 bits rather than 512. That is an issue if you need to be standards compliant since those standards mandated 512 bit keys being accepted in order to inter-operate with export versions.
(Score: 2) by kaszz on Wednesday March 04 2015, @06:09AM
This has all the evidence trail of that organization with big ears in the west. Upgrade time..
(Score: 2) by stormwyrm on Wednesday March 04 2015, @08:16AM
This one really is the NSA's fault. During the era of the so-called Crypto Wars [wikipedia.org] the NSA insisted that the SSL protocol be weakened for export. This attack exploits the remnants of that effort to selectively weaken the protocol.
Numquam ponenda est pluralitas sine necessitate.
(Score: 0) by Anonymous Coward on Wednesday March 04 2015, @06:55AM
(Score: 2) by zeigerpuppy on Wednesday March 04 2015, @07:18AM
While the client acceptance of the older SSL makes this attack work,
I think this is more properly characterized as a server bug rather than a client bug.
Properly configured web servers should not offer encryption on known broken protocols
(Score: 2) by kaszz on Wednesday March 04 2015, @09:28AM
Properly designed protocols should not allow MITM to change configuration..
(Score: 0) by Anonymous Coward on Wednesday March 04 2015, @01:58PM
Which came first? The encryption protocol or MITM?
(Score: 2, Interesting) by idetuxs on Wednesday March 04 2015, @07:44AM
RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204) ==============================================================
Severity: Low
An OpenSSL client will accept the use of an RSA temporary key in a non-export RSA key exchange ciphersuite. A server could present a weak temporary key and downgrade the security of the session.
This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8.
OpenSSL 1.0.1 users should upgrade to 1.0.1k.
OpenSSL 1.0.0 users should upgrade to 1.0.0p.
OpenSSL 0.9.8 users should upgrade to 0.9.8zd.
This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen Henson of the OpenSSL core team.
So why in TFA says that the bug is very important, as "the potential for abuse is very high", but OpenSSL closed the bug as "Severity: Low"?
(Score: 2) by kaszz on Wednesday March 04 2015, @09:26AM
Someone wants others to think it's of low severity? :P
(Score: 1) by WillR on Wednesday March 04 2015, @03:50PM
(Score: 0) by Anonymous Coward on Wednesday March 04 2015, @10:49AM
Err ... how does "Factoring attack on RSA-EXPORT Keys" shorten to "FREAK"? I get "FAREK"! To get "FREAK" I'd need to reorder the words as "Factoring RSA-EXPORT Attack on Keys", but I'm not sure it still makes sense that way.
(Score: 2) by paulej72 on Wednesday March 04 2015, @03:15PM
Team Leader for SN Development