BEAST is said to be fixed in all modern browsers:
It's also fixed in OpenSSL since 2002.
Do these fixes mean that it's safe to use ciphers in CBC mode on TLS 1.0 if end user uses one of these modern browsers?
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.
For more details, see, e.g., TLS 1.0 JavaScript injection vulnerability (BEAST): what to do client-side?; Security impact of the Rizzo/Duong CBC "BEAST" attack; and What can I do about TLS 1.0 javascript injection vulnerability on my server?; How do I use OpenSSL to test for the BEAST attack?; Why was the BEAST attack previously considered implausible?.
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.
Firefox, Chrome, Opera, IE also implemented the following mitigation for the BEAST vulnerability: send just one byte of application data in the first record (aka 1/n-1 record splitting for CBC). This is not perfect, but it should help a lot. In the long run, the right fix is to move everyone to TLS 1.2, but that will take time.
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.
It was fixed recently, so most of the browsers which are now in auto-update are OK, and the server should be setup to negotiate from the AES and not RC_4, and also you can disable SSLv2 completely.
