Lately has been a lot of buzz regarding BEAST  and TLS, including some media hype. Although the attack itself is pretty neat and the demo looks scary, its practicality is very low ; the average user would probably not need to worry about.
In fact there are many other (easier) ways to, e.g. steal someone’s cookies including the old thing called XSS .
Although (aggressively) promoted as a more than a browser attack, the plain reality is that the browser and a SOP(Same Origin Policy) bypass was the main vehicle to resuscitate an old SSL/TLS bug .
BEAST isn’t an attack vector that you should care about, the merit of BEAST is the rattle of the cages of SSL/TLS and the vendors’ state of inability to move forward with its implementation.
SSL 3.0 and TLS 1.0, the most used versions now, date back from 1996 and 1999 respectively. Newer version are available for some time(TLS 1.1, 1996 and TLS 1.2, 2008).
TLS itself, including the latest version might not be perfect. But worrisome is the state of its implementation.
BEAST elegantly brings a reality check on the TLS implementation status, stuck in the past plagued by interoperability issues and with limited options(either cryptographic, e.g ciphers, or else).
Major players: Google, Mozilla(who both uses the NSS library in their browsers), OpenSSL simply contemplated in a laziness state and failed to speed up their implementations.
On the other side: Microsoft, Opera or GnuTLS have stable TLS 1.1 and TLS 1.2 code. Even more, Opera has conducted over the time many test reports pushing their browser on the compatibility edge; at some point in time they even enabled by default support for both TLS 1.1 and TLS 1.2.
So what BEAST did so far:
- accelerate a little bit the need for TLS 1.1 and TLS 1.2 support, both client and server side; although Mozilla isn’t that convinced about TLS 1.2 .
- made IETF attempt to accelerate the interoperability testing to get at least TLS 1.1 support ; although may sound funny, TLS 1.1+ without BEAST probably would have not happened in the near future.
- made IETF attempt to mitigate TLS version fallbacks outside the TLS channel to prevent implementation version rollbacks attacks  that may trigger version specific attacks.
- made obvious the too much dependency of TLS on CBC-based ciphers . The only current alternative was to resurrect RC4 into a prime star although a while ago many(including me) called for stop using it.
- put the jackass badge on Google, Mozilla, OpenSSL  .
- made Microsoft create a Fix it solution  to enable support for TLS 1.1 on capable products.
Unfortunately or fortunately, depends from which point you look, the BEAST is not that powerful to take out SSL 3.0 and TLS 1.0 from patching mode and put them into retirement so soon.
The fix Google Chrome currently implements in the beta version(others will follow ) against the CBC IV attack, splits the non-empty application data records into two records; the first record has only the first byte of plaintext, and the second has the rest.
 BEAST, one of its author’s blog entry
 Chrome and the BEAST
 TLS 1.1 RFC, IV CBC attacks mitigation
 Bug 480514 - Implement TLS 1.2
 [TLS] interop for TLS clients proposing TLSv1.1
 [TLS] One approach to rollback protection
 Slaying BEAST: Mitigating the latest SSL/TLS Vulnerability
 How do I turn on TLS 1.1 or 1.2 and turn off TLS 1.0?
 Bug 565047 - (RFC4346) Implement TLS 1.1 (RFC 4346)
 Bug 665814 - (CVE-2011-3389) Rizzo/Duong chosen plaintext attack on SSL/TLS 1.0 (facilitated by websockets -76)
 Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures
 XSS Flaw on PayPal.com
 Paypal Sender Country XSS
 Microsoft releases Security Advisory 2588513
 ecurity impact of the Rizzo/Duong CBC "BEAST" attack
 Microsoft Security Advisory: Vulnerability in SSL/TLS could allow information disclosure