Need Assistance?

Chat with a representative now.

+1 408 342 5400 / 888 268 4772

Barracuda Product Blog

Impact of BEAST Attacks on TLS/SSL

By Neeraj Khandelwal, Product Manager and Oliver Wai, Product Marketing Manager As you probably heard in the news cycle, there is a new attack on TLS 1.0 demonstrated by security researchers Juliano Rizzo and Thai Duong. The pair dubbed their tool as a Browser Exploit Against SSL/TLS  or “BEAST” and was able to exploit TLS 1.0’s use of encryption algorithms that use cipher block chaining (CBC). In their demo, they were able to decrypt a SSL protected PayPal browser cookie that enabled them to spoof user authentication. The vulnerability is not a new one. It was discovered a number of years ago and resulted in the TLS Working Group to develop the TLS 1.1 standard in 2006 to protect against this attack. Unfortunately, TLS 1.1 were not adopted by the industry due to compatibility issues with existing SSL/TLS deployment and the lack of a practical exploit. Unfortunately with Rizzo and Duong’s demonstrations, the exploit has now moved from the theoretical realm to the real world. For detailed insights on how the attack mechanism works, you can read Eric Rescorla’s analysis here:

http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html

The short of Rescorla’s research is that: A successful attack requires a target domain which allows cross-origin requests that: 1. Contain some user secret (e.g., a cookie) in a predictable location. 2. Allow scripts from the attacker's origin to tightly control additional data on the same HTTPS connection as the user secret, e.g. via Websockets (HTML 5) or Java. It's this mixing of data under control of the attacker and data which should be kept secret from the attacker that constitutes the threat. This is a very natural thing to do in the Web context; mashing up data from one site with another is something that happens all the time. The Web security model is designed to protect you from that, but the lesson here (once again) is that actually getting that right is somewhat tricky.

What is the Implication to me?

In terms of the risk, though this attack does expose plausible ways to exploit the SSLv3/TLS1.0 vulnerability with predictable IVs, it requires a combination of multiple attack vectors. The net of it is that it is still a very difficult attack to exploit:
  1. The attacker must have Man-In-The-Middle (MITM) access to the target
  2. Malicious code Javascript must be injected and run within a browsers session (though the BEAST demo uses a Java Applet)
  3. It requires a website to be able to accept connections from cross domains which is something that is not enabled by high-value sites like a banking application. However same origin policy can be bypassed in an active MITM attack.
  4. It requires the use of CBC based encryption cipher like DES/AES
Based on the available information today, there a number of steps that can be taken to reduce the risk of attack by neutralizing any of the 4 requirements listed above. On the User Side Since the attack requires malicious code to be injected and active within a browser session, a simple behavioral step that can greatly reduce the risk is to restart the browser before logging into a high value, secure website. Basically this means:
  1. Close all browsers tabs and instances.
  2. Re-launch the browser
  3. Go to the secure site
Additionally, avoiding banking, shopping sites, or similar sites on public WIFI networks will greatly reduce the chance of being victim to Man-In-The-Middle (MITM) exploits. On the Client Browser The crux is to avoid using CBC ciphers and use only stream based cipher like RC4 or to enable TLS 1.1 only. More information on mitigation steps by browser vendor are listed below:
Microsoft IE http://blogs.technet.com/b/srd/archive/2011/09/26/is-ssl-broken-more-about-security-advisory-2588513.aspx
Mozilla Firefox http://blog.mozilla.com/security/2011/09/27/attack-against-tls-protected-communications/
Google Chrome Preparing a fix that is in beta/dev testing. This will be pushed out via an automatic update once it is stable.
Apple Safari No response so far
On the Server Side/WAF side The Barracuda WAF supports RC4 ciphers today so client browsers will be able to securely connect to the WAF without fear of the exploit. Additionally the Barracuda WAF can protect against cross origin requests. This is done by enabling CSRF protection. CSRF protection prevents cross-domain requests which reduce the risk of unauthorized access from untrusted 3rd parties. If you have a URL profile created, you can enable CSRF protection under Website->Website Profiles. Click on ‘Edit’ for the URL and then enable CRSF protection: Finally, another preventative step is to reject CBC-based ciphers and enforce TLS 1.1+ which are features that our engineers are fastracking right now. We will send out the update with those features via our Energized Update (EU) infrastructure immediately when it is made available.


Live Chat Support Software