5 ms·

> First, the record split problems caused compat issues. It did, but I think we're through it now. IE, Firefox and Chrome have all had it on for a while.

• tptacek 14y ago
  What scares you more: AES-CBC with best-effort fixes for Lucky 13, or RC4?
  • agl 14y ago
    CBC at the moment I think. There's still the possibility of clients without record splitting, there's timing issues in AES itself, there's lots of possibilities for bad server padding implementations. I have TLS 1.2 and AES-GCM working in NSS on my desktop, but we don't currently have the NSS reviewer time to get it landed. We also have to deal with the issue that an active attacker can trigger a version downgrade somehow. (I don't love AES-GCM either, but it's the nearest port in this storm.) In the mean time, I'll probably tweak RC4 in NSS to send one byte records at the beginning of the connection and thus burn off the first 256 bytes of keystream by encrypting MACs. That still leaves a handful of bytes vulnerable, but half of them will be "GET ". But I doubt that's fully sufficient so AES-GCM is the medium term goal.
    • tptacek 14y ago
      Whoah, neat. I didn't realize the RC4 workaround was that straightforward. Easy to forget you still have the record layer when you're using a stream cipher. Thanks, this was an excellent comment.
    • harshreality 14y ago
      Is this what web security is reduced to? On one hand, openssl not releasing TLS 1.2 support for over 3 years until a semi-panic over BEAST generated enough interest to get it done? On the other, major browser vendors not implementing TLS 1.2 (okay, MS did, but disabled by default) for even longer because lack of server support, compatibility issues, or fear of protocol downgrade attacks made it an uninteresting or risky proposition? Nobody was interested enough to say screw chicken-and-egg and simply get it done, on either side? OS maintainers aren't helping either. RHEL/CentOS 6.4, just released, is still stuck with openssl 1.0.0, which doesn't support TLS 1.1 or 1.2, so there's another few years of webservers running an "enterprise" OS not having TLS 1.2 support. But hey, OpenSSL 1.0.0 is "stable"! I guess there's not much hope of getting Salsa20 or ChaCha, and better curves like curve25519 (I see a draft proposing some Brainpool curves), into TLS 1.2? (with the intent of discouraging many of the less desirable ciphersuites after a few years... not adding more ciphersuites just to add more ciphersuites.)
      • tptacek 14y ago
        What is the advantage of getting Salsa20 or curve25519 into TLS 1.2?
        • aidenn0 14y ago
          djb says they're awesome! But more seriously, salsa is very efficient, so if rc4 is still being used for performance reasons, rather than security reasons, then it would seem to be to be a decent replacement.
          • tptacek 14y ago
            RC4 is fast, but it's being used because Google was forced by circumstance to use it.
        • harshreality 14y ago
          If some catastrophic problem is discovered where there's a practical attack on block ciphers as used in the TLS ciphersuites, with no clever spec-compatible mitigation techniques, it would be nice to have a stream cipher in TLS (and implemented in the major TLS libraries) that isn't known to be problematic like RC4 is. How long would it take to fix TLS implementations for high security applications in that scenario? And what would be the probable response? I think Salsa20 has a good chance of being the "fix"; maybe it wouldn't have to go through a truncated RFC process, and the major stakeholders would simply agree to add it to their TLS implementations and ship, but even then it would take significant time to implement and review. You and others complain about the hodgepodge of ciphersuites in TLS.[1] South Korea gets their obscure block cipher into TLS, and yet the only stream cipher currently in TLS is known to be flawed and hasn't been ripped out and replaced? Curve25519 was an afterthought before I looked and noticed 3 brainpool curves seem to be on track for inclusion, but Curve25519's parameters are more cautiously selected than the curves already in TLS implementations (secp256r1 for instance being the closest equivalent, and a common default curve for ECDH). [1] I can see that the design-TLS-by-committee strategy doesn't seem to be working optimally. Someone credible ought to step up and demand a return to sanity. TLS 1.2 is barely even supported yet in practice, and yet there are 32 AES TLS 1.2 ciphersuites (by openssl 1.0.1e's count, and more that it hasn't implemented), 16 of which are RSA-based?! To take one example, TLS 1.2 RSA ciphersuites that use plain DH... what are they for? The parameters in TLS-enabled applications are traditionally hardcoded for 1024 bit DH, which decreases the security of sites using 2048+ bit rsa keys... and who uses 2048+ bit DH in practice? It's slow, and ECDH is the obvious choice. Then there are lots of less popular ciphersuites (most not even supported by openssl or nss), and as far as I can tell, that's driven by software and hardware companies who want a particular ciphersuite for their commercial products and want it in the official TLS spec, even though that does no good because major TLS libraries will not support obscure ciphersuites.
    • wbl 14y ago
      So what exactly are the NSS reviewers doing instead? Also, could you reorder HTTP headers to put cookies last? And at what point do we say "Screw it, TLS is dead"?
    • agwa 14y ago
      That's a pretty amazing workaround and delightfully ironic that it's made possible by MAC-then-encrypt.