The recent article featured on slashdot http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/ says that connections secured with TLS 1.0 are susceptible to man-in-the-middle decryption (the BEAST exploit). I have an app hosted on Google Appengine, which seems to use TLS 1.0. It relies heavily on javascript, so I can't advise my users to turn it off. What can I do?
-
See security.stackexchange.com/questions/7450/… for what to do on the client end.– Gilles 'SO- stop being evil'Sep 23, 2011 at 12:55
-
blog.torproject.org/blog/tor-and-beast-ssl-attack– LanceBaynesSep 24, 2011 at 8:15
Add a comment
|
5 Answers
Theory of the BEAST Attack
SSL uses various combinations of public and symmetric key algorithms. (OpenSSL's list) When the symmetric algorithm is a block algorithm (as opposed to stream), cipher block chaining is used -- the previous block is part of the input to the new block.
The problems we're seeing right now are implementation-based, and they've been talked at least as far back as 2002. This CBC discussion notes that it's generally really hard to construct chosen plaintext in most protocols. HTTP with Javascript is allowing this to happen.
Why are we still suffering from this
We should be getting away from TLS 1.0 and moving on to 1.2. But of course, we still live in a world with SSL 2. More to the point, even where you can switch to newer TLS versions on your server, the ubiquitous NSS library doesn't support it. That means you wouldn't get Firefox or Chrome visitors.
You can use stream ciphers (RC4), and that will prevent the attack. I don't know if the empty opening message from my first link is used at all, or how that would affect various client implementations.
Your personal reaction
Help write TLS 1.2 into the NSS library. Make others know that you consider security a priority. If you have the time, do some research, testing which non-standard SSL configurations will work and what platforms they negatively affect. If you find out that RC4 works with everything, publish that so we know it has been tested.
If you don't have the time or capacity for that... wait it out. That happens too often, but at least a few folks are being squeaky about it.
answered Sep 22, 2011 at 15:10
-
If you enable newer versions on the server, you'll still be subject to a downgrade attack unless you disable 1.0/1.1. There are browsers with 1.1 support in the wild (IE9, for instance, but it's disabled by default). Still, until you are comfortable turning away all <1.1 traffic, protocol version is not a useful server-side mitigation. Sep 26, 2011 at 1:25
-
2And fwiw, the empty opening message has compat problems (still), but a one-byte opening message works, and is what Chrome is doing. Sep 26, 2011 at 1:31
-
If anyone is wondering why that works, it's because the remainder of the message is filled with random padding, thus defeating any attempt to use the first message as a known initialization vector.– Jeff Ferland ♦Sep 26, 2011 at 11:50
Best thing to do is to wait. There are not enough known details on the attack to assess whether it is a real genuine thing or not, or how it could be fixed. Some details hint at a defect in implementations and may possibly be fixed in the relevant browsers.
answered Sep 22, 2011 at 14:01
-
I think this advice no longer holds since the paper was released. Browsers can indeed fix this unilaterally (well, clients, more generally), but servers still have an independent need to ensure confidentiality, and at least for a while, they can't rely on the client to do the right thing. Sep 26, 2011 at 1:30
Move rc4-based cipher suites to the top of the list; the attack seems to be related to CBC, and rc4-sha is not vulnerable if that is the case.
Update - we've released a white paper here detailing how to make the changes. Available here. To clarify, protocol version won't help you here due to practical considerations - servers cannot disable TLS1.0/SSL3 at the moment due to poor client support, and merely enabling 1.1 still leaves you open to a downgrade attack even if the client does support 1.1. Going to a non-CBC cipher is the only effective server-side mitigation I'm aware of.
Additionally, mail.google.com has switched to RC4 which is not susceptible to the attack, it could very well be that Google app engine has switched too. If you visit the site with SSL, you can click the SSL indicator in the URL bar, click "more information" and see what cipher is being used.
You could get a better insight at SANS Diary Entry at http://isc.sans.edu/diary.html?storyid=11635 the only possible way (discussed at entry above) to counter it at Server is mentioned as disabling the ciphers using CBC
For a better understanding of the BEAST, you could have access to the SSL Paper for it and the Java Code at http://www.insecure.cl/Beast-SSL.rar
