Tuesday, March 3, 2015

SuperFREAK! SuperFREAK! Temptations, sing!

Remember those heady days back when people spelled out W-W-W and H-T-T-P in all their links, and we had to contend with "export only" versions of cryptography because if you let those 1024-bit crypto keys fall into the wrong hands, the terrorists would win? My favourite remnant of those days is this incredibly snide Apple ad where tanks surround the new Power Mac G4, the first personal computer classified by the Pentagon as a munition ("As for Pentium PCs, well ... they're harmless").

Unfortunately, a less amusing remnant of that bygone era has also surfaced in the form of the FREAK attack (see also POODLE, CRIME and BEAST). The idea with export-grade ciphers is that, at the time, those naughty foreign governments would have to make do with encrypting their network traffic using short keylengths that the heroic, not-at-all-dystopian denizens of the NSA could trivially break (which you can translate to mean they're basically broken by design). As a result, virtually no browser today will advertise its support for export-grade ciphers because we're not supposed to be using them anymore after the Feds realized the obvious policy flaw in this approach.

But that doesn't mean they can't use them. And to prove it, the researchers behind FREAK came up with a fuzzing tool that gets in the middle of the secure connection negotiation (which must happen in the clear, in order to negotiate the secure link) and forces the connection to downgrade. Ordinarily you'd realize that something was in the middle because completing the handshaking to get the shared secret between server and client requires a private key, which the malicious intruder doesn't have. But now it has another option: the defective client will accept the downgraded connection with only a 512-bit export-compliant RSA key from the server, trivial to break down with sufficient hardware in this day and age, which the intruder in the middle can also see. The intruder can factor the RSA modulus to recover the decryption key, uses that to decrypt the pre-master secret the client sends back, and, now in possession of the shared secret, can snoop on the connection all it wants (or decrypt stored data it already has). Worse, if the intruder has encrypted data from before and the server never regenerated the RSA key, they can decrypt the previous data as well!

There are two faults here: the server for allowing such a request to downgrade the connection, and the client for accepting deficient keys. One would think that most current servers would not allow this to occur, stopping the attack in practice, and one would be wrong. On the FREAK Attack site (which doubles as a test page), it looks like over a quarter of sites across the IPv4 address space are vulnerable ... including nsa.gov!

What about the client side? Well, that's even worse: currently every Android phone (except if you use Firefox for Android, which I recently switched to because I got tired of Android Chrome crashing all the damn time), every iOS device, and every Mac running Safari or Chrome is vulnerable, along with anything else that ships with a vulnerable version of OpenSSL. Guess what's not? Firefox. Guess what's also not? TenFourFox. NSS does not advertise nor accept export-only keys or ciphers. TenFourFox is not vulnerable to FREAK, nor any current version of Firefox on any platform. Test it yourself.

Classilla is vulnerable in its current configuration. If you go into the settings for security, however, you can disable export-only support and I suggest you do that immediately if you're using Classilla on secure sites. I already intended to disable this for 9.3.4 and now it is guaranteed I will do so.

What about Safari or OmniWeb on Power Macs? I would be interested to hear from 10.5 users, but the test site doesn't work correctly in either browser on 10.4. Unfortunately, because all Macs (including 10.6 through 10.10) are known to be vulnerable, I must assume that both Tiger and Leopard are also vulnerable because they ship a known-defective version of OpenSSL. Installing Leopard WebKit fixes many issues and security problems but does not fix this problem, because it deals with site display and not secure connections: the browser still relies on NSURL and other components which use the compromised SSL library. I would strongly recommend against using a non-Mozilla browser on 10.7 and earlier for secure sites in the future for this reason. If you use Android as I do, it's a great time to move to Firefox for Android. Choice isn't just a "nice thing to have" sometimes.

14 comments:

  1. So, I tested on my 867MHz PowerBook G4 12" running OS X 10.5.8.

    TenFourFox 31.5.0: Not vulnerable (of course)
    Safari 5.0.6: Vulnerable
    Leopard WebKit 537.78.2_4 (latest stable): Vulnerable
    Leopard WebKit 600.5.8 (latest unstable): Vulnerable
    OmniWeb 5.11.2: Vulnerable
    Opera 10.63: Not vulnerable! (It probably has other vulnerabilities though.)

    For what it's worth, Leopard WebKit 600.5.8 does have SSL/TLS-related improvements vs. Safari and Leopard WebKit 537 -- among other changes, it adds TLS 1.1 support and disables SSL 3 (so it is no longer vulnerable to POODLE) -- so maybe there's still hope for a future Leopard WebKit release.

    ReplyDelete
    Replies
    1. It looks like Tobias is also shipping an updated OS X Security component. What does 600.5.7+ do with https://www.ssllabs.com/ssltest/viewMyClient.html and https://www.howsmyssl.com/ ?

      Note that the AEAD ciphers, removal of SHA-1/MD5 and HMAC-SHA256/384 support substantially strengthen TLS 1.2, so it is likely that 1.1 will become deprecated soon as well. But I am encouraged to see _any_ improvement.

      The Opera result is not surprising, however. They also use an independent encryption suite and were known to be quite aggressive about deprecating older portions of the spec as better ones became commonplace. However, as you say, there are probably other shortcomings not yet apparent.

      Delete
    2. The only thing the Qualys SSL Client test complains about (shows in red letters) is the lack of support for TLS 1.2 - and mixed content handling which WebKit never has put much attention to.
      How's my SSL judged that the client is improvable because of lacking support for TLS 1.2 and session tickets.
      All in all medium security feels much better than totally broken security. At least it feels like that...

      Delete
  2. Replies
    1. My suspicion is that all of the WebKit browsers will be vulnerable, because they don't touch the system security components. So I'm interested to see how Tobias created the new security components he's offering in -unstable, if he's still reading. Was it using Apple code, or mixing in patches?

      Delete
    2. Well, I didn't have the time yet to release the patches against the public sources. The sources for the Security framework used to be open source since 10.1 - but without the crypto algorithms libraries, which used to be closed source. But with the release of 10.8 those libraries, comcryption and cryptkit, were released as open source. Instead of extending cryptkit with the new ciphers available with TLS 1.2 Apple had created a new library (kernel module?) named CoreCrypto.
      So rebuilding the Security framework that shipped with 10.5.8 wasn't a big problem. By taking as much code as possible from 10.6.8 support for elliptic curve ciphers was gained. Backporting the ssl library (libsecurity_ssl) from 10.8 brought support for TLS 1.1 and the fix for the POODLE attack.
      In fact the TLS 1.2 handshake is also supported but it seems something related to HMAC-SHA256/384 support is going wrong. AEAD ciphers wouldn't be supported anyway so I didn't consider TLS 1.2 support that important.
      Of course a patch against the FREAK attack will be released soon - maybe today.

      Delete
    3. Still, it's a nice boost. Will the relink script relink against the new security framework as well? (The current unstable one I looked at didn't seem to.)

      Delete
    4. The updated Security framework at least breaks access to the system keychain, so it's not ready for wider use yet.

      The reason why I looked into upgrading the ssl library was originally that some sites like downdetector.com require an elliptic curve cipher and connection isn't possible with OS X earlier than 10.6 .

      Delete
    5. Now I've managed to get TLS 1.2 fully working, including SHA2 !
      That way it's up to date with 10.10 - which also doesn't support anything better than CBC ciphers yet.

      Delete
  3. Well, I can tell you that Opera 27.0 (27.0.1689.76) failed all three web site tests on my late 2014 Mac Mini running OS X 10.10.2.

    Just glad that TFF is not broken on my trusty old G5!

    ReplyDelete
  4. As a side note, I think even IE5 for Mac supports non-export suites, not that it matters much in the long term as Classilla is probably the only classic Mac OS browser that supports SHA2 certificates.

    ReplyDelete
  5. As a side note, US along with the rest of the Wassenaar countries recently raised the limit from 3.0 WT to 8.0 WT:
    http://www.bis.doc.gov/index.php/forms-documents/doc_download/1029-79-fr-45288

    ReplyDelete


  6. (obstinately determined, if self-taught, fledgeling)

    sssssso....when the Leopard Webkit is patched, will it be possible or even conceivable to port that to Tiger?

    ReplyDelete
  7. (this was to enable follow up comments to the above, so reply to this comment please)

    ReplyDelete

Due to an increased frequency of spam, comments are now subject to moderation.