BEAST stands for Browser Exploit Against SSL/TLS. It is an attack against network vulnerabilities in TLS 1.0 and older SSL protocols. The attack was first performed in 2011 by security researchers Thai Duong and Juliano Rizzo but the theoretical vulnerability was discovered in 2002 by Phillip Rogaway.

Why do we want to talk about such an old attack technique? According to research done for the 2020 Acunetix Web Application Vulnerability Report, 30.7% of scanned web servers still have vulnerable TLS 1.0 enabled, which means that they are susceptible to the BEAST attack.

This shows how IT security is still a major issue for businesses and no matter how many new features improving security are introduced in software, old attacks are still a major problem. This situation also applies to SSL/TLS vulnerabilities including BEAST, BREACH, POODLE, or OpenSSL Heartbleed.

How Does the BEAST Attack Work

The Transport Layer Security (TLS) protocol is a successor to Secure Sockets Layer (SSL). Both are cryptographic protocols that let you use different cipher suites to encrypt the communication between a web browser and a web server. This makes it impossible for someone to listen in on the communication and steal confidential data.

Attackers may be able to tap into the conversation between a web server and a web browser using man-in-the-middle attack techniques. If they do and if there is no encryption, they have access to all the information exchanged between the web server and web browser: passwords, credit card numbers, etc.

However, even encryption might have its weaknesses and be broken. This is exactly the case with the BEAST attack. The researchers found that TLS 1.0 (and older) encryption can be broken quickly, giving the attacker an opportunity to listen in on the conversation.

If your server supports TLS 1.0, the attacker can make it believe that this is the only protocol that the client can use. This is called a protocol downgrade attack. Then, the attacker can use the BEAST attack to eavesdrop.

Technical Details of BEAST

The TLS protocol uses symmetric encryption with block ciphers. Symmetric encryption means that the same key is needed to encrypt and decrypt the message. Block ciphers mean that information is encrypted in blocks of data that have fixed length. If there is not enough data for the last block, that last block is padded. Some popular block ciphers are DES, 3DES, and AES.

If the same data and the same key always gave the same encrypted content, an attacker could easily break any encryption. That is why TLS uses initialization vectors. This means, that encryption is seeded using random content. This way, if you use the same data and the same key many times, every time you end up with different encrypted content.

However, it would not be efficient to use random data to seed every block in a block cipher. That is why SSL/TLS also uses cipher block chaining (CBC). Blocks are chained with one another using a logical XOR operation. In practice, this means that the value of each block depends on the value of the previous block. So, an encrypted value representing some original data depends on the previous block of that data.

The Attack Technique

The basic principle of breaking codes is: everything can be broken, it’s just a matter of how long it takes. The same principle applies to SSL/TLS ciphers. A good cipher is not impossible to break. It is simply impractical to break – impossible to break in a sensible amount of time using current computing resources.

The attacker could break a block cipher by trying different combinations and seeing if they get the same result with the same initialization vector (which they know). However, they can only check that for a whole block at a time, and a block can have, for example, 16 bytes. This means that for the block to be checked, the attacker would have to test 25616 combinations (3.4028237e+38) for every block.

What the BEAST attack does is make this much simpler: the attacker only needs to guess a single byte at a time. This can be done if the attacker can predict most of the data (for example, HTML code) and needs just one piece of secret information, for example, a password. The attacker can then test the encryption carefully, selecting the right length of the data, so that they have just one byte of information in a block that they do not know. And then, they can test the block just for 256 combinations of this byte. Then, they repeat the process for the next byte, soon coming up with the entire password.

Is BEAST a Practical Attack?

A BEAST attack is not easy to perform. The attacker must use a different exploit to become a man-in-the-middle and to inject content into the stream. The researchers who discovered this vulnerability used a Java applet but an attacker can also use JavaScript. Even if the attacker tricks the user into running vulnerable Java or JavaScript code, the web application is by default protected using same-origin policy and this makes injection impossible (unless the web application has server-side CORS headers that override the default policy).

The difficulty of the attack is why this vulnerability is rarely exploited, despite a third of the websites still supporting the vulnerable TLS 1.0 protocol (according to our statistics). However, it is possible and therefore you should protect yourself against it.

How to Discover if Your Web Server Is Vulnerable to BEAST

Discovering whether your web server is vulnerable to BEAST is very easy. If it supports TLS 1.0 or any version of SSL, it is vulnerable to BEAST.

You can easily discover if your web server supports TLS 1.0 or any version of SSL using Acunetix or manually. The advantage of using Acunetix is: you will also find all your web vulnerabilities that other tools won’t discover. And what’s the point of fixing just one vulnerability and not even knowing about others, which may be just as dangerous?

BEAST shows the major difference between web vulnerabilities and network vulnerabilities: network vulnerabilities are very easy to detect even using free tools and the only way to eliminate them is to upgrade affected software or hardware. Web vulnerabilities must be detected by specialized software like Acunetix and they can be eliminated by fixing application code.

How to Fix the BEAST Vulnerability

Originally, the RC4 cipher was recommended for use to mitigate BEAST attacks (because it is a stream cipher, not a block cipher). However, RC4 was later found to be unsafe. Currently, PCI DSS (Payment Card Industry Data Security Standard) prohibits the use of this cipher. Therefore, you should never use this method to protect yourself from BEAST.

Just as with other network vulnerabilities, there is just one simple fix to BEAST: turn off TLS 1.0 and older protocols. Here is how you can do it for the most popular web server software. What we recommend is also disabling TLS version 1.1 and leaving just TLS 1.2 running (all major browsers such as Google Chrome, Firefox, and Safari support TLS 1.2).

Apache Web Server

Edit the SSLProtocol directive in the ssl.conf file, which is usually located in /etc/httpd/conf.d/ssl.conf. For example, if you have:

SSLProtocol all -SSLv3

change it to:

SSLProtocol TLSv1.2

Then, restart httpd.


Edit the ssl_protocols directive in the nginx.conf file. For example, if you have:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

change it to:

ssl_protocols TLSv1.2;

Then, restart nginx.

Microsoft IIS

To disable TLS 1.0 in Microsoft IIS, you must edit the registry settings in the Microsoft Windows operating system.

  1. Open the registry editor
  2. Find the key HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server
  3. Change the DWORD value of the Enabled entry to 0.
  4. Create a DisabledByDefault entry and change the DWORD value to 1.

Repeat the above steps for all versions of SSL and TLS 1.1 (if you want to go along with our recommendation and disable it, too).

Tomasz Andrzej Nidecki
Principal Cybersecurity Writer
Tomasz Andrzej Nidecki (also known as tonid) is a Primary Cybersecurity Writer at Invicti, focusing on Acunetix. A journalist, translator, and technical writer with 25 years of IT experience, Tomasz has been the Managing Editor of the hakin9 IT Security magazine in its early years and used to run a major technical blog dedicated to email security.