'Bar Mitzvah Attack' Plagues SSL/TLS Encryption

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.

Comments

'Bar Mitzvah Attack' Plagues SSL/TLS Encryption

[ArcadeMan]

But only on Jewish websites.

I kid, of course. Mel Brooks rules!

Duh

[Anonymous Coward]

It's been well over a decade since the weaknesses of RC4 have been widely disseminated. No surprises here.

Re:Duh

[Dragonslicer]

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

[thegarbz]

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.

Re:Duh

[arglebargle_xiv]

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 in some way of removing these ancient, flaw-riddled mechanisms.

Re:Duh

[thegarbz]

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:Duh

[Anonymous Coward]

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:Duh

[petermgreen]

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.

Bar Mitzvah?

[Anonymous Coward]

Jews did RC4!

Re: 'Bar Mitzvah Attack' Plagues SSL/TLS Encryptio

[Anonymous Coward]

I hear the attack cuts your connection a little shorter.

I miss vulns with CVE numbers or bug tracker IDs.

[mr_mischief]

I really hate how every little thing gets some catchy marketing name now that is hard to search. Just give me the damn CVE.

Bar Mitzvah attack?

[GammaKitsune]

Oy vey!

Re: I miss vulns with CVE numbers or bug tracker I

[Anonymous Coward]

A-freaking-men, brother. Amen.

CipherList

[manu0601]

Good CipherList for OpenSSL based applications: ECDH@STRENGTH:DH@STRENGTH:HIGH:!RC4:!MD5:!DES:!aNULL:!eNULL

Next step is to add !3DES

Re:CipherList

[Anonymous Coward]

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 + EDDH + any safe curve (like curve25519, I think that's the name) manages to get past the IETF NSA liason that likes to stonewall these things (he's a WG chair. Darn conflict of interest, that, even if the guy is a really good cryptographer), we will have a light at the end of the tunnel. It will take a couple years to deploy, though.

Re:CipherList

[manu0601]

I know elliptic curve in Dual_EC_DRBG had a backdoor planted by the NSA. I am not aware of any problem with elliptic curve usage in ECDHE. Do you have a reference to a document telling otherwise?

why not saying only simply attack on RC4

[ruir]

Tired of bullshit names....what next, the Lewinsky attack on Linux?

Re:why not saying only simply attack on RC4

[Anonymous Coward]

Correct Horse Battery Staple

Slashdot from 2013 calling :)

[DougPaulson]

"Dan Bernstein presented a method for breaking TLS and SSL web encryption when it's combined with the popular stream cipher RC4 invented by Ron Rivest in 1987", Thursday March 14, 2013

Financial Institutions outdated

[grahammm]

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?

Re:I miss vulns with CVE numbers or bug tracker ID

[twokay]

I think the easiest way is to start getting security researchers to use ridiculous names, like the new SSH vulnerability "Smelly Fart".