2 Answers
2

I don't think anyone knows of any way to exploit BEAST, on any of those modern browsers, so as far as anyone knows, those browsers are probably pretty safe against BEAST-like attacks. On the other hand, the underlying weakness is still present, which leaves some room for concern about the possibility that someone might find a new way to exploit that weakness.

BEAST exploits a security weakness in TLS 1.0. The principled way to close the entire weakness is to update both the browser and the server to TLS 1.1 or TLS 1.2. At the moment, Chrome supports TLS 1.1; IE9, IE10, Opera support TLS 1.1 and TLS 1.2 if you set a special option, but support is not enabled by default; iOS 5 client supports up to TLS 1.2; Firefox and Safari do not. Unfortunately, both endpoints have to support TLS 1.1 before you can establish a TLS 1.1 connection, and today, few servers support TLS 1.1 or TLS 1.2. A few servers support TLS 1.2 (e.g., Apache with mod_gnutls; IIS 7 if you enable some special registry keys; Java app servers on Java 7), but only a very few. This means that it will be exceedingly rare that anyone can use TLS 1.1 or TLS 1.2 today. Therefore, the principled fix to the BEAST attack is not widely deployed today, no matter what browser you use.

That said, several servers have implemented some workarounds that help mitigate the known ways of exploiting this weakness in TLS 1.0. These workarounds are a "stopgap" that do not make the weakness go away, but they do prevent all known ways of exploiting the weakness. The primary mitigation is to ensure that both sides use RC4, instead of any block cipher based mode of operation. Servers can arrange this by changing the order of their ciphersuites. You can test whether your server is configured in a way that should prevent BEAST using this SSL tester.

I can understand why you might have gotten the impression you did. The earliest attack exploited this weakness using WebSockets. A later attack showed how to exploit it using Java, too. Most modern browsers have now been patched to change how WebSockets works, so that WebSockets can no longer be used to exploit this weakness. However, the underlying weakness is still present, and I don't think anyone would be terribly surprised if tomorrow someone discovered a new way to exploit the weakness without using WebSockets or Java.

Another footnote: while many browsers are starting to implement support for TLS 1.1, there is a significant caveat. Just turning on TLS 1.1 or 1.2 causes compatibility problems with buggy servers. Those servers fail if a client indicates that it supports the newer TLS versions. Therefore, browsers try TLS 1.1, but if that fails, they try again using TLS 1.0. If TLS 1.0 fails, they will further fallback to SSL 3.0. This introduces a vulnerability: a man-in-the-middle can force both sides to fall back to TLS 1.0.

@AndreyBotalov, I don't know of anything wrong with that scheme.
–
D.W.Aug 13 '12 at 1:11

Why have you written "This is not perfect, but it should help a lot."? I think browsers won't implement those measures if they won't be perfect
–
Andrey BotalovAug 13 '12 at 10:34

About paragraph starting with "I can understand why you might have gotten the impression you did." I have this impression not because of this. Fixes made by browsers to solve BEAST issue aren't about WebSockets, Java etc. I'd want to delete this paragraph but I don't know whether it will be appropriate
–
Andrey BotalovAug 13 '12 at 11:07