Lately has been a lot of buzz regarding BEAST [1][2] and TLS, including some media hype. Although the attack itself is pretty neat and the demo looks scary, its practicality is very low [2][14]; 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 [12][13].
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 [3][11][16].
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, 2006 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 [4].
- made IETF attempt to accelerate the interoperability testing to get at least TLS 1.1 support [5]; 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 [6] that may trigger version specific attacks.
- made obvious the too much dependency of TLS on CBC-based ciphers [7]. 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 [8] [9].
- made Microsoft create a Fix it solution [17] 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 [10]) 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.
References
[1] BEAST, one of its author’s blog entry
http://vnhacker.blogspot.com/2011/09/beast.html
[2] Chrome and the BEAST
http://www.imperialviolet.org/2011/09/23/chromeandbeast.html
[3] TLS 1.1 RFC, IV CBC attacks mitigation
http://tools.ietf.org/html/rfc4346#section-1.1
[4] Bug 480514 - Implement TLS 1.2
https://bugzilla.mozilla.org/show_bug.cgi?id=480514#c32
[5] [TLS] interop for TLS clients proposing TLSv1.1
http://www.ietf.org/mail-archive/web/tls/current/msg08070.html
[6] [TLS] One approach to rollback protection
http://www.ietf.org/mail-archive/web/tls/current/msg08099.html
[7] Slaying BEAST: Mitigating the latest SSL/TLS Vulnerability
http://www.phonefactor.com/blog/slaying-beast-mitigating-the-latest-ssltls-vulnerability.php
[8] How do I turn on TLS 1.1 or 1.2 and turn off TLS 1.0?
http://www.google.com/support/forum/p/Chrome/thread?tid=0539619c98f85cbb&hl=en
[9] Bug 565047 - (RFC4346) Implement TLS 1.1 (RFC 4346)
https://bugzilla.mozilla.org/show_bug.cgi?id=565047#c59
[10] Bug 665814 - (CVE-2011-3389) Rizzo/Duong chosen plaintext attack on SSL/TLS 1.0 (facilitated by websockets -76)
https://bugzilla.mozilla.org/show_bug.cgi?id=665814
[11] Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures
http://www.openssl.org/~bodo/tls-cbc.txt
[12] XSS Flaw on PayPal.com
http://praetorianprefect.com/archives/2010/03/xss-flaw-on-paypal-com/
[13] Paypal Sender Country XSS
http://praetorianprefect.com/archives/2010/10/paypal-sender-country-xss/
[14] Microsoft releases Security Advisory 2588513
http://blogs.technet.com/b/msrc/archive/2011/09/26/microsoft-releases-security-advisory-2588513.aspx
[15] CVE-2011-3389
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3389
[16] ecurity impact of the Rizzo/Duong CBC "BEAST" attack
http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html
[17] Microsoft Security Advisory: Vulnerability in SSL/TLS could allow information disclosure
http://support.microsoft.com/kb/2588513