As it turns out, the attack itself was conceived years ago, deemed impractical, but it was nevertheless fixed in TLS 1.1. The new attack technique introduced a few optimizations to make it practical.
In terms of mitigation, I expect this problem will be largely addressed on the client side, despite a potential compatibility problem that may cause some TLS sites to stop working. The only reliable way to defend against BEAST is to prioritise RC4 cipher suites, as proposed by PhoneFactor.
Just as an example, here's one way to do the above in Apache:
Not everyone likes RC4, even though there is little to no evidence that it is insecure in the context of SSL/TLS. If your server supports TLS 1.2+ you can try the approach recommended by Steve Caligo:
The idea is that you put a few TLS 1.2 cipher suites first so that they can be picked up by TLS 1.2 clients, which are not vulnerable, followed by RC4 for TLS 1.0 clients.
Now that I've discussed what works as mitigation, let's look at a few approaches that do not work:
- Supporting TLS 1.1+ server-side is a good start, but does not amount to much because very few clients support newer versions of the protocol at this time. And even with TLS 1.1+ support client-side, there's nothing preventing the MITM to force a protocol downgrade back to TLS 1.0. (For a discussion on defense techniques against downgrade attacks, see this thread on the TLS WG mailing list).
- Enabling the empty fragment technique server-side (details for OpenSSL here) does not work either. TLS 1.0 uses two initialisation vectors (IVs), one each for client- and server-side of the communication channel. The vulnerability exploited by BEAST is on the client-side and cannot be addressed by making server-side changes to how data is sent.
- Compression is said to make the attack impossible, but, as with TLS 1.1+, the support for it client-side is inconsistent.