Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Encryption Safari Security

FREAK Attack Threatens SSL Clients 89

Posted by Soulskill from the another-day-another-vuln dept.
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.
This discussion has been archived. No new comments can be posted.

FREAK Attack Threatens SSL Clients More

FREAK Attack Threatens SSL Clients

Comments Filter:

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

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

      by chill ( 34294 ) on Tuesday March 03, 2015 @04:56PM (#49175663) Journal

      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.

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

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

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

      by halivar ( 535827 )

      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.

    • So the arconym is FARK? Sponsored by Drew.

    • Re: (Score:3, Funny)

      by TechyImmigrant ( 175943 )

      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?

  • As Matthew Green points out: [cryptograp...eering.com]

    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.

    • Actually, the reason "export strength" RSA even exists is because of U.S. law classifying long-key RSA the same as military hardware. In other words, you could be sent to prison for selling it outside the U.S. If the FBI/NSA had their way back in the 1990s, everyone would be using this weak kind of "security" today.

      • Re: (Score:2)

        by bulled ( 956533 )
        AFAICT that is the point that Mr Green is making. If you let policy purposefully weaken security, it will eventually be exploited. "Nobody but us" is a fallacy.

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

    by SIGBUS ( 8236 ) on Tuesday March 03, 2015 @04:48PM (#49175597) Homepage

    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)

      by jo_ham ( 604554 )

      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.

  • Heh (Score:2)

    by waspleg ( 316038 )

    â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

  • "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 an HTTPS-protected website configured to use a weak cipher that many had presumed had been retired [arstechnica.com]. At the time this post was being prepared, Windows devices were not believed to be affected, and the status of Linux devices was unknown"
  • So would clients built using the SSL libraries from the (stripped-down, un-borked) version of SSL that the OpenBSD team recently did - LibreSSL [libressl.org] - vulnerable as well?

    • Re: (Score:1)

      by Anonymous Coward

      No. LibreSSL deleted all the EXPORT stuff. Not vulnerable.

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

    • 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

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

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

        by kesuki ( 321456 )

        "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)

      by Whip ( 4737 )

      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.

      • 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

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

    by Opportunist ( 166417 ) on Tuesday March 03, 2015 @06:49PM (#49176645)

    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!

  • I didn't see it mentioned in the article or summary which ones are affected. All I saw is "including OpenSSL." How about an actual list of affected software? Or maybe I'm just blind and missed it, but I don't think so.

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

    by ledow ( 319597 )

    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

    • 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

Slashdot Top Deals

"The pyramid is opening!" "Which one?" "The one with the ever-widening hole in it!" -- The Firesign Theatre

Close