6

It is common practice to prevent the BEAST attack using the following ciphers in Apache SSL configuration:

SSLCipherSuite RC4-SHA:HIGH:!ADH

Unfortunately, RC4 has been found to be flawed and it is now recommended to avoid its use.

From a Nessus report:

SSL RC4 Cipher Suites Supported

The remote host supports the use of RC4 in one or more cipher suites. The RC4 cipher is flawed in its generation of a pseudo-random stream of bytes so that a wide variety of small biases are introduced into the stream, decreasing its randomness.

If plaintext is repeatedly encrypted (e.g. HTTP cookies), and an attacker is able to obtain many (i.e. tens of millions) ciphertexts, the attacker may be able to derive the plaintext.

Solution

Reconfigure the affected application, if possible, to avoid use of RC4 ciphers. Consider using TLS 1.2 with AES-GCM suites subject to browser and web server support.

I have tried to use the following ciphers in my Apache SSL configuration:

SSLCipherSuite HIGH:!ADH:!MD5

Unfortunately, this is vulnerable to BEAST. How can I prevent this without using RC4 cipher suites?

We run on CentOS 6.5 and use the following SSL protocols:

SSLProtocol -ALL -SSLv3 +TLSv1
Xander
  • 35,525
  • 27
  • 113
  • 141
Michael
  • 1,457
  • 1
  • 18
  • 36
  • 1
    Simple: Don't prevent BEAST. It was fixed in the TLS 1.1 protocol, and decent TLS 1.0 clients have implemented 0/n or 1/n-1 record splitting to work around and solve BEAST as well. – Matt Nordhoff Oct 31 '14 at 06:28
  • Thanks! So, If I use Apache SSL and client is recent browsers the BEAST vulnerability should be solved. Correct? – Michael Oct 31 '14 at 07:22
  • 1
    Stop disallowing TLS 1.1 and 1.2, use [a better ciphersuite](https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations), and you’ll be fine. – Ry- Oct 31 '14 at 19:37
  • Since still 90% of Worldwide Websites are vulnerable to BEAST (see the current trustwortycomputing Stats), since TLS1.0 can still be used generally and seemingly lots of the Server Stacks simply have not been mitigated or updated Server-Side by preventing specific CipherSuites (or simply preventing the use of TLS1.0 at all because there is already and meanwhile absolutely no excuse for not using TLS1.2 only since all major Browsers support it, along with completely dropping RC4 for https) it is - IMHO - required to address this now by a RFC Guideline specification which will not say that TLS1. –  Dec 13 '15 at 10:27

1 Answers1

11

BEAST is a client-side attack, so all you can do on the server side is to avoid letting unaware clients put themselves in a BEAST-vulnerable position. However, modern clients (Web browsers) are not vulnerable to BEAST anyway:

  • Clients use record splitting (usually 1/n-1) as a countermeasure.
  • BEAST requires the hostile in-browser code (in Java or Javascript) to be able to send requests to the target site with arbitrary byte values; no method for doing that is currently known (at the time of the BEAST demo, the authors had found two flaws that allowed that, but they were both fixed since that time).

A client that is still vulnerable to BEAST is a client that has not been updated for several years, which means that it already has bigger problems.

A more general solution is to use TLS 1.1 or 1.2, which are not vulnerable to that specific attack. However, even when clients support such protocols, they also tend to indulge in unbridled reconnections that make them vulnerable to protocol downgrade attacks.

Arguably, tools and people who whine and grind their teeth about BEAST are in sore need of an update themselves. "BEAST prevention" has turned into a toxic dogma, parroted ad nauseam without any decent understanding of what it really means.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949