Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Bug Encryption Security

'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.
This discussion has been archived. No new comments can be posted.

'Bar Mitzvah Attack' Plagues SSL/TLS Encryption

Comments Filter:
  • by ArcadeMan ( 2766669 ) on Thursday March 26, 2015 @03:20PM (#49348965)

    But only on Jewish websites.

    I kid, of course. Mel Brooks rules!

  • by Anonymous Coward

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

    • Re:Duh (Score:5, Interesting)

      by Dragonslicer ( 991472 ) on Thursday March 26, 2015 @03:59PM (#49349365)

      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)

        by thegarbz ( 1787294 ) on Thursday March 26, 2015 @05:06PM (#49349955)

        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].

        • 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

          • 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.

            • by 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.

          • 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.

  • by mr_mischief ( 456295 ) on Thursday March 26, 2015 @04:47PM (#49349809) Journal
    I really hate how every little thing gets some catchy marketing name now that is hard to search. Just give me the damn CVE.
    • by twokay ( 979515 )
      I think the easiest way is to start getting security researchers to use ridiculous names, like the new SSH vulnerability "Smelly Fart".
  • by manu0601 ( 2221348 ) on Thursday March 26, 2015 @09:45PM (#49351561)

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

    Next step is to add !3DES

    • by 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

      • 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?
  • by ruir ( 2709173 ) on Thursday March 26, 2015 @11:03PM (#49351919)
    Tired of bullshit names....what next, the Lewinsky attack on Linux?
  • by DougPaulson ( 4034537 ) on Friday March 27, 2015 @12:24AM (#49352173)
    "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 [slashdot.org]
  • 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?

The only thing worse than X Windows: (X Windows) - X

Working...