FREAK Attack Threatens SSL Clients 89
msm1267 writes: For the nth time in the last couple of years, security experts are warning about a new Internet-scale vulnerability, this time in some popular SSL clients. The flaw allows an attacker to force clients to downgrade to weakened ciphers and break their supposedly encrypted communications through a man-in-the-middle attack. Researchers recently discovered that some SSL clients, including OpenSSL, will accept weak RSA keys–known as export-grade keys–without asking for those keys. Export-grade refers to 512-bit RSA keys, the key strength that was approved by the United States government for export overseas. This was an artifact from decades ago and it was thought that most servers and clients had long ago abandoned such weak ciphers. The vulnerability affects a variety of clients, most notably Apple's Safari browser.
Is there any way to block the use of old ciphers? (Score:2)
I know you can configure some options for PGP to block the use of insecure ciphers, but is there any way to configure a Linux/Debian box so that it refuses to accept insecure ciphers by default? Not just for the browser, but globally for all SSL connections.
Re: (Score:3)
The SSL implementation is NOT part of the kernel.
Re: (Score:2)
You could implement your own version of the SSL libraries that don't implement "weak" encryption protocols. When confronted by a client/server session that tried to default to the vulnerable mode, the client would get a "no failover" error message. The homebrew version would be no help in "forcing" a secure SSL session, and the browser/server would not be standards "compliant". Oh well. Oh, it would have to be a browser with available source code; hello firefox, goodbye safari.
Re:Is there any way to block the use of old cipher (Score:4, Interesting)
Yes. http://www.openssl.org/docs/apps/ciphers.html [openssl.org]
The question is does OpenSSL accept the weak ciphers as a downgrade bug even when EXPLICITLY DISALLOWD.
I haven't seen answered in any of the linked articles so am digging/testing.
After the last couple of bugs my organization set the explicit cipher/algorithm/has acceptable list. The export ciphers were excluded on purpose from our list.
SSL Labs https://www.ssllabs.com/ [ssllabs.com] has a recommended list buried in their documentation somewhere.
Re:Is there any way to block the use of old cipher (Score:4, Informative)
Answering myself to preserve the thread.
It looks like the export cipher suite must be enabled for this to work. So if you didn't turn off old, busted ciphers then you're potentially vulnerable.
Meh. Set your approved cipher suite and be done with it.
Re:Is there any way to block the use of old cipher (Score:4, Informative)
I extensively make use of this site for cypher selection:
https://wiki.mozilla.org/Secur... [mozilla.org]
There are 3 levels of configuration proposed which you can use as a starting base for your own selection. The EXPORT cyphers are explicitely marked as 'Mandatory discards'. Any serious website running with these cyphers should be fined for exposing their visitors.
Re: (Score:2)
Just configuring openssl is not enough. Theres at least THREE different SSL libraries in common use on linux and the chances are you have applications using all of them.
Re: Is there any way to block the use of old ciphe (Score:2)
I was thinking server side, for the web server. But yes, you need to ensure every service you provide that uses TLS is properly configured.
I'm not sure how much this would impact something like SMTP-S or IMAPS, since the connection duration on those types of service is so short.
The big target is going to be web servers.
Re: (Score:2)
You could theoretically do some packet inspection on the handshake and send a spoofed RST if you see something during the exchange you don't like.
I've only ever dug into the certificate exchange portion of the handshake. I'm assuming the cipher negotiation is also in the clear.
FREAK (Score:2)
Factoring Attack on RSA-EXPORT Keys
Why do people go to the trouble of making an acronym if they're going to screw it up anyway?
Re: (Score:3)
Or, you know ... Factoring-attack on RSA-Export Keys.
Seriously, there's a lot of different ways to do an acronym (or a backronym as this likely is).
My suggestion? Get over it.
Re: (Score:2)
Yeah, shoulda used Friggin' Radical Exploit Attacking Keys.
If you are a GO or NGO in need of creative backronyms, I can be purchased for moderately wasteful sums of cash.
Re: (Score:3)
So the arconym is FARK? Sponsored by Drew.
Re: (Score:3, Funny)
Factoring Attack on RSA-EXPORT Keys
Why do people go to the trouble of making an acronym if they're going to screw it up anyway?
Factoring Attack on Rsa-exporT keys?
Re: (Score:2)
MITM positioning is a prerequisite, but that's not hard if you run a Wi-Fi hotspot. This is a bid-down attack, tampering with initial negotiation to limit the cipher suite and strength to something more breakable without raising alarms.
If you can additionally prevent the use of PFS cipher suites so the 512 bit key is used for pre-master secret encipherment, you need only break the static 512-bit key once to read all the traffic protected by it.
Re: (Score:3)
512 bits isn't a very high a bar anymore.
It took 6 months and 8000 MIPS-years to factor RSA-155 back in 1999.
According to Dhrystone, the CPU in the computer I'm typing this post on could do those 8000 MIPS-years in roughly 3 weeks and you could probably knock that down to less than a day if you brought the GPU into the matter, let alone something with some real oomph.
Re: Safari browser? Hmm (Score:2)
Google forked their own version of SSL called Googlessl. My guess is chrome would use this.
The big question is Googles implementation based on openssl or libressl? The bug might still be there if former
Re: (Score:2)
Because there's still a difference if the local police department has a key to your house or whether the lock is easily picked with a coat hanger without leaving any traces of trespassing.
You see, it's not ONLY the government that's out to get you.
Re: (Score:2)
Generations have been told to use, supplied with or trusted brands. The more weak tame code that is found, the more people can talk about how.
The real story is (Score:2)
This might be academic if it was just a history lesson — but for the past several months, U.S. and European politicians have been publicly mooting the notion of a new set of cryptographic backdoors in systems we use today. This would involve deliberately weakening technology so that governments can intercept and read our conversations. While officials are carefully avoiding the term “back door” — or any suggestion of weakening our encryption systes — this is wishful thinking.
Re: The real story is (Score:1)
Re: (Score:2)
Damn you Putin! (Score:1)
Just because the NSA is trying to weaken encryption standards, why do you have to pile on too!
Firefox OK, Chrome needs fixing (Score:5, Informative)
I tried the test on up-to-date Firefox (36.0) and it's immune, but Chrome on Android (40.0.2214.109) is vulnerable.
Re: (Score:3)
Also interesting to note here that according to Slashdot, it's official that Safari is more notable than Chrome.
Must be market share or something.
Re: (Score:1)
Heh (Score:2)
âoeIn practice, I donâ(TM)t think this is a terribly big issue, but only because you have to have many âoeducks in a rowâ: 1) find a vulnerable server that offers export cipher suites; 2) it should reuse a key for a long time; 3) break key; 4) find vulnerable client; 5) attack via MITM (easy to do on a local network or wifi; not so easy otherwise),â said Ivan Ristic of Qualys.
(Unless you're the NSA, then you have more MITM "opportunities" than you have people to exploit them...autom
Arstechnica post fake Apple/android security alert (Score:3)
LibreSSL / OpenBSD vulnerable as well? (Score:3)
Re: (Score:1)
No. LibreSSL deleted all the EXPORT stuff. Not vulnerable.
Ciphersuite Negotiation (Score:2)
Ciphersuite Negotiation is a liability. A good security protocol will not have it. It is empirically impossible to get right.
Pick one set of algorithms, good enough for the lifetime of the device or system and any changes are done by replacing the single static suite on both ends, say once per decade. Make the whole thing so utterly simple to implement that it would be hard to get wrong.
Re: (Score:3)
One set of algorithms, good for the lifetime of the device... hmm... you mean, like, say, SSLv3 until about 6 months ago? If we hadn't found POODLE, it would still meet all criteria for a good, secure algo for the foreseeable future. At the very least for the lifetime of any device build within the last year (until about 6 months, of course).
There is no such thing as "guaranteed to be secure for the lifetime of a device". All it takes is to find a fundamental flaw in the algorithm (like, well, POODLE) and w
Re: (Score:2)
I mean like crypto algorithms with lots of security headroom. 256 bit keys and no known attacks, or equivalent security. DJBsque Edwards curve ECC to minimize the implementation errors that keep cropping up. No X.509 because it's seems impossible to implement securely. And on an on.
TLS is not fit for purposes. We should stop pretending and replace it. That's what I'm working on.
Re: (Score:2)
Again, any algo considered secure today may be rendered useless by a discovery tomorrow. That's the nature of cryptography. Time and again we have seen that what we considered "unbreakable" (within reasonable time) offered some side channel attack or an implementation flaw (or worse, as in SSL3, a design flaw that CANNOT be patched) that turned it into a useless waste of computing cycles.
You cannot "promise" that whatever protocol, implementation or procedure you offer will be secure for the next X days/wee
Re: (Score:2)
"One set of algorithms, good for the lifetime of the device..."
well the easy way to do that is set the device lifetime to 5 seconds. it takes 6 seconds to look up a rainbow table.
Re: (Score:2)
No negotiation, replace the suite on both ends once per decade.
So, what... the Internet gets together and decides that January 1 of every year ending with '0' we'll upgrade every server, client, and embedded system in the world to the latest security protocol while disabling the previous decade's? And people whose systems are out of support or can't be patched (which would only be, what, 80% of the current internet?) are just SOL?
I think I see some flaws in your plan.
Re: (Score:2)
One of the problems with TLS is we keep adding better ciphers, but the old weak ciphers hang around and implementation errors leave us vulnerable to downgrade attacks. A big problem with negotiable cipher suites is the inability to retire old ciphers. We might like to think it can be done, but it isn't a solved problem and TLS is a prime example of that failure.
But crypto has moved on a long way and we have a lot more of the basic crypto functions coming with mathematical proofs of the hardness bounds of at
Re: (Score:2)
I keep seeing people declare TLS's cipher choices to be mess and propose cleaning them up somehome. Look deeper. The problem is not adding things, it is retiring things. If you can't retire algorithms, you can't clean up. If you can't clean up, then negotiation is bad.
So you have to live with your initial choices. Make them well.
OpenSSL and export suites (Score:2)
What is sad is that OpenSSL disabled the EXPORT1024 ciphersuites in 2006. If you don't know what these are, in year 1999 the US government raised the limit to 56-bit encryption and 1024-bit RSA. They were described in https://tools.ietf.org/html/dr... [ietf.org] . And for the record it was in year 2000 that the restrictions was removed for "retail" software.
And this, kids, is why you configure your servers (Score:4, Insightful)
Because clients are run by idiots. Sorry, but it's true.
Clients are run by people who look at the funny acronyms and you can watch their eyes glaze over. If they know anything about it, they will know that there are keys and these keys depend on how big the number next to them is. That there are symmetric and asymmetric keys and that 512bit can be a LOT if it's symmetric and insignificantly little if it's asymmetric is already something you won't be able to teach them.
So configure your servers, people. Configure them to ONLY accept sensible ciphers. Yes, that means that people with Internet Explorer 5 might not be able to use your page. Then inform them to fucking get a browser that was made in this millennium! These people are a security risk and bluntly, if you want to do business with them, you do not want to do business with me.
Or at least I don't want to do business with you!
Re: (Score:2)
Then you're part of the problem.
If vendors didn't pander to people running IE 5 then they would sack the fuck up and call their nephew to spend 5 minutes installing Teamviewer and Google Chrome.
People who refuse to run modern shit on their hardware may be the majority, but only because assholes are willing to bend over backwards selling them "lazy" as a commodity.
Not sure what the GP is going on about.
In my observations, retiring Windows XP drastically reduced the number of issues from "my stuff doesn't work, it's new, I bought it 10 years ago, why not?" complaints.
There was a small cadre of folks re-installing XP on new machines (I did it too) because there wasn't a reason not to. After Nosebleed and Hearbeep (or whatever) happened last year I shut off old ciphers on all my stuff. And know what? NOBODY NOTICED. I get an occasional hit from China or other shit
Re: (Score:2)
Users who are stuck using browsers that are incapable of applying more up-to-date ciphers are nowhere close to the majority. They're over an order of magnitude away from being the majority, in fact.
Re: (Score:2)
For others joining, apk is referring back to this single-sentence post of mine [slashdot.org] and the ensuing thread.
Anyway, I have some time to kill and karma to burn.
AdBlock doesn't do a FRACTION of what hosts can and for FAR LESS resources consumed... period/fact!
I agree entirely that extensions are far less efficient than hosts. I'm inclined to disagree that the extensions do less hosts, but it's not a point worth arguing for me. What's more important is that, as I already said in response to you [slashdot.org], this isn't an either/or. Use both, since each of them does stuff better than the other. Hosts can't do everything that
Re: (Score:2)
(Sorry for the delay...was out of town this weekend and just got back)
Oh, is that all you were asking? The simple answer is that I didn't say I used hosts prior to my first response to you. My original post was constrained to the topic of ad-blocking extensions, hence why I didn't mention the fact that I also use hosts to complement the extension(s), and hosts hadn't come up otherwise at any time recently, so you're correct about it not being in my recent comment history. I don't know why you think that I w
Re: (Score:2)
See subject: You screwed up & never said you use hosts once there (prior to your saying you did AFTER you gave me guff telling me to "read more closely")...
I think I understand the confusion now. The "read more closely" comment wasn't related to my using hosts. As you correctly said, you couldn't possibly know that I used hosts until I said so, and I said I used it in the same comment where I said "read more closely". The "read more closely" comment was in relation to the fact that you posted an attack on AdBlock in response to my initial post, presumably because you thought my initial post was a defense of AdBlock (which it wasn't), which I believed was the r
Re: (Score:2)
If we're constraining your assertion to ad-blocking addons, then I'd be willing to concede that they may indeed be both lesser-featured and less efficient (I'm not willing to do the research necessary to ascertain whether it's true or not). Even so, I still contend that some have features that hosts lacks, and that as a result they remain useful as a complement to hosts.
If we're talking about addons in general, as your assertion was originally phrased, then no, hosts does not do more than any addon. Off the
Re: (Score:2)
I'm simply asserting that hosts and ad-blocking addons do different things and that they're best used together, rather than to the exclusion of the other, but that where their features do overlap, I readily agree that hosts is more efficient. I'm fairly certain that's already a valid stance, and if we can't agree on it, I'm not going to argue it further.
Likewise, I'm not going to argue about which of them "does more". I don't know how you'd objectively quantify that, nor do I see why that matters at all, no
Re: (Score:2)
You can't argue in favor of "Almost ALL Ads Blocked" [...]
Let me stop you right there.
You keep repeating that quote over and over again as if it's something I said, yet never once did I say or argue that. Stop putting words in my mouth. If you'll cease treating me as an antagonist and will stop constructing straw men arguments for a moment, you'll find that we already agree on almost everything and have been from the start.
It's SO nice NOBODY can prove it wrong... TRUTH is like that.
I agree. Your list is valid. I never argued otherwise. That's also why I never directly addressed it, since there's no point in addressing topi
Re: (Score:2)
I had to put YOUR WORDS in your mouth
Except that they weren't my words. I can speak for myself.
You couldn't even remember NOT noting hosts in our exchange originally!
Sure I could...once I understood that that's what you were asking, but it took two or three posts before I even understood what you wanted. Once I did, I realized I had miscommunicated earlier, so I clarified what I had said.
Hosts work on ANY browser (or app) on a PC operating system - not just "some" as you said...
I did not say it only worked on some. In my very first response I even listed hosts' ability to work across browsers and services as one of its major benefits.
My only claim regarding browser-specific functionality was related to
Re: (Score:2)
To me, this was never a debate at all, since we're on the same side: people should be using hosts, and tools like the one you make are beneficial in helping people to use hosts more easily.
I'm just sad you haven't realized we're on the same side yet and have continued resorting to antagonistic approaches towards me. I mean, what would I "EVER try" again: telling people to ditch AdBlock because it's inferior to alternatives? Because that's what started this whole discussion.
Re: (Score:2)
That wasn't intended to be antagonistic towards you, though I can certainly see how it would be taken that way since it was expressed rather rudely of me, so I do apologize for that. What I was trying to convey is that you're undermining your own arguments with your style of posting. It was your way of expressing your idea that I took issue with, not you.
When I saw your original response to me, I read a few of the bolded phrases and came to the incorrect determination that it was a spam post from one of the
Re: (Score:2)
I didn't call you a crazy spammer. I said you looked like one with the way you formatted your post, and I stand by that claim. You're welcome to disagree or disregard what I've said.
As for your points, I already said I agreed with all of them...
It's SO nice NOBODY can prove it wrong... TRUTH is like that.
I agree. Your list is valid. I never argued otherwise. That's also why I never directly addressed it, since there's no point in addressing topics that we agree on.
And I really did dismiss your original post as a spam post, just based on the way it was presented. It really wasn't until your second post that I realized you weren't a spammer. Whether you believe that or not is entirely your choice, but it is the truth. Take it in
Which ones? (Score:1)
Re: (Score:2)
https://freakattack.com/ [freakattack.com]
Is this really an issue? (Score:2)
It's a downgrade attack that uses ancient old ciphers. Can we assume that any site that is vulnerable to FREAK is also vulnerable to other downgrade attacks and generally is likely to use old and insecure ciphers?
I mean if you score an A on ssllabs tests which already penalise you for weak ciphers it shouldn't be an issue right?
TLS (Score:2)
Sigh.
So, as I understand it, the current situation is:
- We can't allow use of RC4 because it's weakened significantly.
- If we disallow RC4, we open ourselves up to BEAST in practical terms.
- We need to move towards PFS and TLS 1.2 but the major libraries don't support it in major stable versions and/or we break an awful lot of the world's clients in doing so.
- A lot of the chain certificates out there are still using only SHA1 which makes them weak.
- And now we have to start worrying about clients that allo
Re: (Score:2)
It's not as bad as you think it is.
-RC4 is weak, but the BEAST attack is mostly resolved on clients, and SSLLabs doesn't even penalize you for it anymore.
-TLS1.2 and lack of PFS only really breaks IE at this point, and not the latest version either. In many cases you can sleep at night. Not implementing PFS still doesn't open you up to the major attacks on SSL that are presently out there and will allow IE to work.
-Chain certificate issues are administration problems, and there's no reason not to re-issue y