'Bar Mitzvah Attack' Plagues SSL/TLS Encryption 23
ancientribe writes Once again, SSL/TLS encryption is getting dogged by outdated and weak options that make it less secure. This time, it's the weak keys in the older RC4 crypto algorithm, which can be abused such that an attacker can sniff credentials or other data in an SSL session, according to a researcher who revealed the hack today at Black Hat Asia in Singapore.
A slice: Bar Mitzvah exploits the weak keys used by RC4 and allows an attacker to recover plain text from the encrypted information, potentially exposing account credentials, credit card data, or other sensitive information. And unlike previous SSL hacks, this one doesn't require an active man-in-the-middle session, just passive sniffing or eavesdropping on SSL/TLS-encrypted connections, [researcher Itsik] Mantin says. But MITM could be used as well, though, for hijacking a session, he says.
'Bar Mitzvah Attack' Plagues SSL/TLS Encryption (Score:4, Funny)
But only on Jewish websites.
I kid, of course. Mel Brooks rules!
Re: 'Bar Mitzvah Attack' Plagues SSL/TLS Encryptio (Score:5, Funny)
I hear the attack cuts your connection a little shorter.
Duh (Score:1)
It's been well over a decade since the weaknesses of RC4 have been widely disseminated. No surprises here.
Re:Duh (Score:5, Interesting)
It's been well over a decade since the weaknesses of RC4 have been widely disseminated. No surprises here.
The summary fails to mention (anyone surprised?) that this is where the name comes from. Apparently the flaws have been known for 13 years.
Re:Duh (Score:5, Informative)
The flaws in RC4 have been known about for a long time but were thought irrelevant in the scheme of SSL/TLS to the point where RC4 was the preferred cipher suit only a few years ago as it was one of the few that were able to mitigate the BEAST attack. So the GP's comment that there's no surprise since RC4 has been known to be weak for a decade isn't quite the full story.
It was only in 2013 where RC4 became strictly taboo for use in SSL/TLS with the exposure of new exploitable vulnerabilities on top of the several previous weaknesses identified, and last month RFC7465 effectively banned the cipher's use in TLS [ietf.org].
Re: (Score:2)
The flaws in RC4 have been known about for a long time but were thought irrelevant in the scheme of SSL/TLS to the point where RC4 was the preferred cipher suit only a few years ago as it was one of the few that were able to mitigate the BEAST attack. So the GP's comment that there's no surprise since RC4 has been known to be weak for a decade isn't quite the full story.
At least part of the fault lies in the TLS standard and standards process itself. While TLS includes extensive processes for adding new mechanisms of all types to the protocol (and dear God has there been a mountain of crap shovelled in there over the years), there's no procedure whatsoever for taking things out (apart from the very ad-hoc "ZOMG THE SKY IS FALLING TELL EVERYONE NOT TO USE THIS ANY MORE" approach). So the single biggest step towards fixing these problems (there's many of them) is to build i
Re: (Score:2)
Well part of the problem is screwing backwards compatibility with older clients. I mean I personally have secured my website with SSL to the nth degree, but I can't even access it with IE8/9 on a Vista machine and that's a browser. Imagine the amount of older software that wouldn't work if we removed every cipher on a whim.
Re: (Score:1)
That's the beauty of it. Get rid of the unsecure crap, force people to use something up-to-date.
And if you're worried about hardware obsolescence caused by that, the answer is to enforce an "update for the next 10 years" rule on all consumer devices. Will cut down drastically on environment waste, too.
Or just use open-source software, where keeping things up-to-date is a cheaper problem to solve.
Re: (Score:2)
The whole internet standards process works based on "asking nicely". You can tell people they shouldn't use an option or even that by using that option they will be non-compliant with the latest version of the standard but you can't really stop them from using it if they decide that compatibility with old clients outweighs security.
I miss vulns with CVE numbers or bug tracker IDs. (Score:5, Insightful)
Re: (Score:1)
Bar Mitzvah attack? (Score:1)
Oy vey!
CipherList (Score:3)
Good CipherList for OpenSSL based applications: ECDH@STRENGTH:DH@STRENGTH:HIGH:!RC4:!MD5:!DES:!aNULL:!eNULL
Next step is to add !3DES
Re: (Score:1)
ECDH is not safe, unless you can shoehorn it to not use the NIST curves.
At least, if the Huawei people are to be believed, they were quite adamant that their stuff doesn't support suite-B because they have very very very strong reasons not to.
And if you have an RNG malfunction with ECDH, your keys are leaked. Such as the one that plagued FreeBSD *DEVEL* (not stable/release) a couple months ago.
Sometimes PFS (protocol forward secrecy, there is nothing "perfect" in PFS) is not worth the hassle.
Now, if EdDSA
Re: (Score:2)
why not saying only simply attack on RC4 (Score:4, Funny)
Slashdot from 2013 calling :) (Score:3, Interesting)
Financial Institutions outdated (Score:2)
While I know that it is a generalisation, but many financial institutions seem to be using these deprecated TLS/SSL options. For example not supporting any PFS ciphersuites and some even only offering RC4 even to modern browsers. This despite their claims that 'security is one of their top priorities'. Financial institutions are amongst those most in need of good data security, so why are they still using these outdated protocols?