FREAK on a leash



  • http://www.washingtonpost.com/blogs/the-switch/wp/2015/03/03/freak-flaw-undermines-security-for-apple-and-google-users-researchers-discover/

    Users of Apple and Google devices? Your machine can be tricked into accepting 512-bit RSA keys, which can be easily cracked by modern computers in a few hours.



  • Could they make their headline a little less idiotic, maybe?

    Google’s Chrome browser is not vulnerable to the FREAK bug, but the
    browser that comes built into most Android devices is vulnerable.

    It's not just Nexus phones. And possibly not Chromebooks at all.


  • FoxDev

    Google’s Chrome browser is not vulnerable to the FREAK bug, but the browser that comes built into most Android devices is vulnerable.

    The browser that's built into most Android devices is Chrome…



  • I haven't used Android in awhile, but it used to have a separate "Android Browser" that was definitely NOT Chrome. (Although it might have used Chromium, I don't know.)

    In any case, the point is: there are a decent number of browsers and of web servers left that will happily accept these weak-ass keys.



  • @RaceProUK said:

    The browser that's built into most Android devices is Chrome…

    That's true for devices that a) are at or above 4.0 and b) include the Google Play services. Older/low end devices can't get Chrome, and devices without Play services (unlicensed third parties, custom roms, etc) won't have it by default.

    Also some manufacturers/carriers may have their own idea about what browser should be included.



  • @aliceif said:

    Could they make their headline a little less idiotic, maybe?

    And can't they come up with a less embarrassing exploit name, while they're at it?


  • Grade A Premium Asshole

    @RaceProUK said:

    The browser that's built into most Android devices is Chrome…

    Only on the newest devices. Before 4.1 (I think? Maybe 4.0?) there was another browser that came stock.

    Also, that is not to say that one flavor of Chrome is not vulnerable (like desktop) and another is (mobile).

    @blakeyrat said:

    can be tricked into accepting 512-bit RSA keys

    Am I the only one who can still remember when 128-bit RSA keys seemed like an insurmountable level of security? Like such a thing could never be broken?



  • @Polygeekery said:

    Am I the only one who can still remember when 128-bit RSA keys seemed like an insurmountable level of security? Like such a thing could never be broken?

    Yes. This is like Paradigm City in Big O, where literally everybody lost their memory a few years ago and we're all kind of just struggling to figure out what happened and who we are. Also tomatos are involved somehow.

    You are the only one who can remember the past, and also there's a giant robot in the subway system also-somehow.


  • Grade A Premium Asshole

    You're in a mood today...



  • Meh, don't really have much work to do.


  • Grade A Premium Asshole

    @blakeyrat said:

    Paradigm City

    Oh yes, ticket queue is low. Shouldn't you be training or something?


  • BINNED

    @Polygeekery said:

    Shouldn't you be training or something?

    He never said what he's training though. Maybe it's trolling.


  • Grade A Premium Asshole

    Also, anime and MST3K.





  • @blakeyrat said:

    Users of Apple and Google devices? Your machine can be tricked into accepting 512-bit RSA keys, which can be easily cracked by modern computers in a few hours.

    At first I read it as SHA-512, and wondered when the hell did we find computers the size of the Universe.

    RSA, though? I didn't even know a 512-bit version exists until now.


  • Grade A Premium Asshole

    Best part of the article:

    "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 systems — this is wishful thinking. Our systems are already so complex that even normal issues stress them to the breaking point. There's no room for new backdoors."



  • I'm trying to find out if Microsoft's TLS libraries are vulnerable to this, and I haven't seen anything about it on any of the articles I've dug up. (I assume not-- especially since Microsoft researchers helped discover it, but I'd like to see a definitive statement to know if we should be updating our IIS or not.)

    Has anybody tracked down a definitive list of affected servers/clients?


  • FoxDev

    Not a list of servers/clients, but this is the CVE:

    Looks like the issue is in OpenSSL, and appears to be specific to SSL3; doesn't look like MS's TLS library is affected.



  • Ok, that's good news. It does make me wonder if "export-quality" is on by default in IIS, though.

    EDIT: AFAICT it's not. But I don't know what version of IIS turned it off.

    EDIT: Here's a list for Vista/Server 2008 and up: https://msdn.microsoft.com/en-us/library/aa374757(v=vs.85).aspx

    You need to go back to Server 2003 or XP to find a version of Windows that supports the "export-quality" encryption, so Microsoft's fixed this quite awhile ago.


  • Fake News

    Consumer-grade security is shit? Hoocoodanode!

    Sent from my BlackBerry Passport.



  • @blakeyrat said:

    I'm trying to find out if Microsoft's TLS libraries are vulnerable to this

    Trust me, if they were, you'd have heard about that already.



  • I understand the bug is on the client implementation, but shouldn't the onus be on the centralized servers to stop offering export-grade RSA keys?


  • Discourse touched me in a no-no place

    @dstopia said:

    shouldn't the onus be on the centralized servers

    Whose centralized servers are we talking about here?



  • Sorry, I hadn't had enough coffee yet. The idea was that the onus should be on the service providers to stop the vulnerability short on their side, having a tighter control on what their stuff does (as opposed to the gazillion different vendor Android versions and how difficult it is to get rid of old versions of things in consumer devices).

    I mean, there was a bug in OpenSSL that affected practically everything that uses OpenSSL, but if service providers stops offering export-grade encryption, it becomes (sort of) a non issue.

    Granted, in the end it becomes as impossible as upgrading every single Android version of OpenSSL, but for the important service providers (Facebook, Twitter, your bank website) things should get rolling immediately.



  • Good thing this website is "safe" ...


  • Discourse touched me in a no-no place

    @dstopia said:

    The idea was that the onus should be on the service providers to stop the vulnerability short on their side, having a tighter control on what their stuff does (as opposed to the gazillion different vendor Android versions and how difficult it is to get rid of old versions of things in consumer devices).

    OK, that's meaningful on the grounds that it is presumably not in the interest of the providers of services to have it be easy for the malicious to trick ordinary users in to believing that they are using the service when they aren't. Reputation cost, etc. Unfortunately, so many smaller service providers are cheap in stupid ways. (So too are larger providers and users, but the former have to deal with so much shit that they need their operations right anyway, and the latter… oh well.)



  • @dstopia said:

    I understand the bug is on the client implementation, but shouldn't the onus be on the centralized servers to stop offering export-grade RSA keys?

    The problem's on both sides, but I think it's a case where the problem's 400 times worse for the server owner.

    EDIT:

    @dstopia said:

    I mean, there was a bug in OpenSSL that affected practically everything that uses OpenSSL, but if service providers stops offering export-grade encryption, it becomes (sort of) a non issue.

    The bug here is that the servers don't offer export-grade to the client. (Meaning: it's not on the list of acceptable protocols given to the client.) But if the client comes back with, "ok, here's some export grade shit", the servers won't reject it. The bug's in the negotiation code, in other words.

    Microsoft's solution is just to completely and utterly remove the entire concept of export grade from the OS back in 2007. Probably the best solution here-- even if their negotiation code were broken, there's no way the client could connect with export-grade encryption because it's simply not implemented at all.



  • As far as I understood, the actual attack requires the TLS server to have the export-grade shit enabled. From the article you posted:

    The MITM attack works as follows:
    In the client's Hello message, it asks for a standard 'RSA' ciphersuite.
    The MITM attacker changes this message to ask for 'export RSA'.
    The server responds with a 512-bit export RSA key, signed with its long-term key.
    The client accepts this weak key due to the OpenSSL/SecureTransport bug.
    The attacker factors the RSA modulus to recover the corresponding RSA decryption key.
    When the client encrypts the 'pre-master secret' to the server, the attacker can now decrypt it to recover the TLS 'master secret'.
    From here on out, the attacker sees plaintext and can inject anything it wants.

    For that to happen, as I understood from reading around, the TLS server needs to have an option enabled to accept export-grade ciphers. The actual bug is in the client accepting the export-grade cipher back even when it didn't ask for it.



  • Oh maybe. I don't know.

    As soon as I remove the servers I run from consideration, I give no shits for your loser Linux bugs.


  • BINNED

    @aliceif said:

    Good thing this website is "safe" ...

    As in, nobody dares to screw with it for fear of the revenge of the nerds that would surely follow?



  • Because Atwood wasn't involved in configuring the web server.



  • @blakeyrat said:

    Yes. This is like Paradigm City in Big O, where literally everybody lost their memory a few years ago and we're all kind of just struggling to figure out what happened and who we are. Also tomatos are involved somehow.

    You are the only one who can remember the past, and also there's a giant robot in the subway system also-somehow.

    Showtime.



  • @kilroo said:

    Showtime.

    Always bugged me that his catchphrase was the same as Jem's.



  • @hungrier said:

    @RaceProUK said:
    The browser that's built into most Android devices is Chrome…

    That's true for devices that a) are at or above 4.0 and b) include the Google Play services. Older/low end devices can't get Chrome, and devices without Play services (unlicensed third parties, custom roms, etc) won't have it by default.

    Actually, the default browser on my LG G3 is just "Browser". Though Chrome was also installed by default. It has been running 4.4 since I bought it.



  • Oh hey lookie here:

    It looks like the "security downgrade" part of the FREAK attack does work on MS products. The saving grace is that Microsoft's lowest-possible security bar is a hell of a lot higher than export-grade RSA.

    EDIT: or maybe not; the advisory specifically says an attacker can switch to export-quality. Hmm. Either way, Microsoft doesn't seem to be in any particular panic over it.



  • The attacker can switch to export-quality ciphers if Secure Channel is configured to use them. Which it hasn't been, by default, since Windows XP.


Log in to reply