Unfortunately, the only way to mitigate the BEAST attack is to enforce the use of RC4 suites whenever TLS 1.0 and earlier protocols are used (which is most of the time at this point). I say "unfortunately", because very shortly after we had started requiring server-side mitigations, new research about RC4 came out and we found out that this cipher was much weaker than previously thought. The weaknesses were not of immediate concern, but it was clear that RC4 was on the way out.
The situation became uncomfortable because we couldn't solve both problems, but also because both issues were of roughly the same risk. (Low.) Still, the end result was clear: RC4 affects everyone and cannot be mitigated; BEAST affects only a part of the user base and there isn't a workable exploitation path for it any more (we hoped). In addition, we knew that attacks against RC4 were going to get better; and that the attack surface vulnerable to BEAST likely to get smaller.
Is BEAST still a threat?
From this conclusion, the work that remained was to prove that the exploitation path used by BEAST was genuinely closed. We had no reliable information about that, and so I set out to test a bunch of browsers running on various platforms, read source code where available, and attempt to exploit BEAST myself.
The research required a lot of effort and time, mostly because I did not want just to run the existing exploit; I wanted to fully understand the attack as well as explore other potential attack vectors. Juliano and Thai (BEAST authors) have been very helpful answering my questions about their choices. I had detours, some because of real problems, some because of my mistakes. For a long time I thought BEAST was still exploitable because, to my great surprise, I discovered that the Same-Origin Policy (SOP) bypass that was used for BEAST still existed. Apparently, the fix for that problem was botched. Using this bypass, a MITM can still use a Java applet to instrument a victim's browser to encrypt arbitrary plaintext and send it to arbitrary hosts.
Fortunately, there have been many changes to how applets work since BEAST was originally discovered. For example, there are now always warnings before an applet is started. In my testing, the Java plug-in had no ability to access HttpOnly cookies; it couldn't even send them in a request, or receive any of them back. Most importantly, HTTPS request made by applets are encrypted using Java's TLS stack, not that of the host browser. Because Java does implement the 1/n-1 split, BEAST cannot be exploited.
By subscribing to our early morning news update, you will receive a daily digest of the latest security news published on Help Net Security.
With over 500 issues so far, reading our newsletter every Monday morning will keep you up-to-date with security risks out there.