Is SSL/TLS Really Broken by the BEAST attack? What is the Real Story? What Should I Do?

September 21st, 2011

Update – January, 2015.  SSL v3 should be turned off.  RC4 is now weak and should not be used anymore, even as a work around to the BEAST attack.  LuxSci recommends to use TLS v1.1+ and NIST-recommended ciphers.  The BEAST is not really considered a significant vector (even with TLS v1.0) compared to other things, anymore.

Update – April, 2012. openssl v1.0.1 is out and it supports TLS v1.1 and v1.2 which help mitigate this attack.  All web sites hosted by LuxSci now use this updated software and are safe from BEAST.  LuxSci recommends using a web host which supports TLS v1.1 and v1.2 for secure web connections.


SSL v3 and TLS v1 are subject to a serious exploit, according to a recently published attack mechanism (called BEAST).  This sounds foundation-shattering and kind of scary. When people see this, as when we did, the first panicky questions that arise are:

  • What is really affected?
  • How serious is it?
  • What can I do to protect myself?
  • How does the BEAST attack actually work?

After researching this issue, we have digested what we have found and produced this article to answer all of these questions for you.

What is really affected by BEAST?

This problem can affect people browsing secure web sites, allowing eavesdroppers to gain full access to your accounts on those web sites under certain conditions.  It does not affect

It does affect:

  • Accounts you may have with secure web sites that you login to, like PayPal, LuxSci, Gmail, Bank of America, Facebook, etc.

When could my web site browsing be compromised?

If you are using a network where someone malicious can view all normal traffic on the network, and where they can also intercept and modify that traffic, then they can try to compromise your secure web site browsing.

Note that this does not include bad people using the same wifi network or ISP as you, who can eavesdrop on your insecure connections — SSL is still an effective defense against them.   It does include situations where, for example:

  • The folks in charge of your local network are malicious.
  • Malicious folks have broken into your local network and have gained control over its servers.
  • You are in a country where all network traffic into and out of it is monitored.

People who are not in malicious countries and are using networks that are “trusted” probably do not have to worry too much.  By “trusted”, we mean

  • The administrators as your local ISP (i.e. Comcast, AOL, Verizon, etc.) are usually trusted.  We already trust them to a large degree — if they wanted to they could compromise our systems much more easily than using this TLS attack (i.e. by designing Trojans or viruses and introducing them into our systems)
  • The IT staff running your school or work network are usually trusted.  (Well, the people at work already “own” everything you do in their network.)  And, like ISP operations staff, the administrators of these networks could do much worse things to you much more easily than this TLS attack, if they wanted to.
  • The Government — do you trust them to not force ISPs to eavesdrop on you?  Even if they were doing this, depending on the Government involved and the situation, most people would have little to worry about.

This attack is an issue of organizations that want to eavesdrop on your communications or access your accounts without your knowledge and who either (a) already know what web sites you frequent, or (b) have access to enough people’s web traffic that they just try to compromise accounts of very popular places like Gmail, PayPal, or certain Banks.

If you are not the trusting sort, you see that there is a significant threat potential here that depends on where you are and what you are doing.

Under what conditions can I be compromised?

Simply put, if there is an attack made against you, you could be compromised if:

  1. You load up any insecure web page (i.e. the web page address starts with http:// and not https://) and have JavaScript enabled in your browser.
  2. You keep browsing the Internet using the same browser for up to 10 minutes
  3. You then visit that secure web site which the attacker desires to be able to access as you.

Note that the attacker needs to guess or know about 10 minutes ahead of time what secure web site you are going to visit.  This timeframe of 10 minutes will get shorter and shorter as more computer power is brought to bear in the attacks.

As an example, let us assume that the attacker is trying to eavesdrop on everyone’s Gmail account accesses in order to gain usernames, passwords, and other sensitive data.

  1. When you visit an insecure web page (like
  2. The attacker beings gathering and processing data for accessing
  3. You surf around for a while,
  4. You visit to check your email
  5. The attacker is able to use the information gathered to access your Gmail account as if they had just logged in as you.

How can I protect myself?

If you are concerned about this attack, you can protect yourself from it by:

  • Closing your browser (all open windows)
  • Open your browser and go directly to the desired secure site without connecting to any insecure sites first.

This works because the attack requires the same browser session be used for a period of time.  Closing and re-opening your browser negates any preparation work done by the attacker.  Starting in a secure (https://) web browsing session prevents the attacker from even getting started.

You can accomplish this without much effort by:

  1. Make your “home page” (the page that opens when you start your web browser) a secure page.  I.e.  Then you can use browser-bookmarks to your favorite secure sites to navigate to them from your initial secure page.
  2. Put  bookmarks to frequently visited secure web sites on your desktop, so when you click on them your browser is opened and you go directly to that secure page.
  3. Disable JavaScript in your browser.  Alternately, configure your browser to only allow JavaScript with specific trusted secure sites.
  4. Use a VPN (virtual private network).  If you connect your computer to a network you do trust (like work), this sends all your secure and insecure web connections over the VPN bypassing any ability of a malicious person in your local network from viewing or interfering with any of your web browsing.

Also, if your attacker doesn’t know your browsing habits, then they are unlikely to compromise your browsing of secure sites that are not very, very popular.  I.e. sites like, facebook,com,, and other ones that very large numbers of people visit are likely targets.  Smaller sites like are not.  However, if the attacker knows where you visit, all bets are off in this respect.

How does the BEAST attack actually work?

  1. When you visit an insecure web page, the attacker alters the returned page or returned JavaScript to add malicious JavaScript to the content that you download.
  2. This malicious JavaScript runs automatically in your web browser (if you have use of JavaScript enabled)
  3. The JavaScript opens a secure connection to (for example)
  4. The attacker compares the encrypted traffic between your browser and with the known data that was sent by the JavaScript.  Using several minutes of computer processing power, the attacker can figure out something called the “Initialization Vector” of your secure session.
  5. This information allows them to access the future secure authentication cookies sent to the same web site in the same browser session.
  6. These cookies can be “replayed” by the attacker to give them full access to your account as if they were already logged in.  They can see any sensitive data that you have there and perform actions as you.

It is important to note that:

  • This attack requires JavaScript in a web browser to work.
  • It requires an insecure web connection be made and for the attacker to be able to modify the content returned to you.
  • The attacker must guess what secure web site you will visit.
  • The attacker must have time to gather and analyze data.
  • You must then connect to and login to that same web site in the same browser session (i.e. without closing and re-opening your browser or using a different browser).
  • The attacker must use that site as you while your logged in session is active (if you explicitly logout, that would usually also logout the attacker; lets hope the attacker has not changed your password on you!).


  • This attack affects SSL v3 and its successor, TLS v1.0
  • It does not affect web sites using TLS v1.1 or TLS v1.2 for encryption

Well, can I just use “TLS v1.1” or “TLS v1.2”?

The answer is “Yes, kind of”.

  • Only the Internet Explorer and Opera web browsers support TLS v1.1 and higher.  All other web browsers (i.e. Google Chrome, FireFox, Safari, and probably most if not all mobile browsers) do not support these newer security protocols at all.  Also, even though Internet Explorer does support these, they are generally disabled by default.  There is also some concern that enabling them can cause issues accessing some regular secure web sites — i.e. if you enable it and some sites no longer work, you know what happened.
  • Most web servers do not support TLS v1.1 or TLS v1.2 yet, so even if your browser supports it, your target secure site probably does not — i.e. does not, does not, does not, etc. According to Opera only 0.25% of web servers support TLS v1.1 or better – that is NOT 25% that is one quarter of one percent!

Why do most servers not support the better TLS v1.1+?

  • The standard production-quality SSL software libraries, like “openssl“, do not yet include TLS v1.1 support so most web sites cannot enable it.  While the newest still-in-development openssl versions do support TLS v1.1, these are obviously not yet included in the standard operating system install distributions and there are concerns about performance, reliability, and bugs.
  • There has not been a strong need for TLS v1.1 and v1.2 support up until now.

LuxSci is contacting the various vendors (like RedHat) to see if perhaps TLS v1.1 support will be incorporated into existing distributions so that everyone out there who depends on these can upgrade easily.

The alternatives — use some other SSL system or use a very new openssl distribution that has not been well vetted  in the context of peoples’ servers — are both very unattractive as they would require many updates, lots of lots of testing, and probably some downtime to install and push out across an organization.  Use of alternative software would also mean that any future openssl security updates need to be managed either manually or via some new to-be-implemented update mechanisms.  All very unattractive — that is why these alternate solutions are not in wide use yet, in deference to the standard auto-updating non-TLS v1.1-supporting versions.

Despite this, is currently investigating adding TLS v1.1 support to its secure web servers as it is the right thing to do and the sooner the better.

You can check the SSL-capabilities of any web site you like and also see if it supports TLS v1.1 or v1.2 by using this SSLLabs web site.

What about the Web Browser updates?

The browser manufacturers are currently investigating this issue and the extent to which it makes their users vulnerable.  We would expect them to issue some browser software updates that mitigate this attack to some degree without needing web servers to upgrade to TLS v1.1. While web server upgrades are, of course, desirable in the long run, they certainly won’t happen fast.

Microsoft considers the threat level of this issue relatively low; FireFox is looking to develop a “Fix” soon; other TLS experts are not overly concerned at the moment.

The Take Away Message

People should always be concerned and aware of security as the landscape changes constantly.  We think that beyond the need to upgrade and to implement software fixes, consider the following:

  • We should actually use SSL and TLS whenever possible. Insecure sites puts our browser and computer at risk, as we have no control over what malicious third party may inject into our browsing session.  SSL and TLS actually protect us from that threat.
  • When going to secured web sites, it is best to start in a new browsing session or one that has only visited other secure (https://)  sites.
  • Make your home page a secure site and your other secure sites easily-accessed via bookmarks
  • Use a separate web browsers for normal insecure browsing and for access to your secure sites.
  • Keep your software, web browsers, operating system, anti-virus, and other components up to date.

If/when browser manufacturers push out fixes for this problem, the “threat level” will significantly decrease (it is low at the moment anyway as there are probably few if any people out there actively using this attack vector yet).

However, it is very likely that similar attacks that hijack insecure connections for various reasons will continue to arise in the future.  It would be a good habit to use separate browsers for your secure and insecure browsing, as described above.

Proactive security habits are a good thing.