Mitigation of CVE-2011-3389 (BEAST) for web server administrators

Products

• Support Only for Apache HTTP
• VMware vSphere ESXi
• VMware vSphere ESXi 5.0
• VMware vCenter Server

Issue/Introduction

Researchers recently demonstrated a practical man-in-the-middle (MITM) attack for retrieving small amounts of information from encrypted SSL communication between a browser and web server. This is reported as CVE-2011-3389, a browser or cryptography library vulnerability, nicknamed BEAST (Browser Exploit Against SSL/TLS). While the primary way to block the vulnerability is to update vulnerable browsers, this article discusses mitigation from the web server administrator standpoint.

This is a client issue. While VMware recommends that all customers follow their browser vendors advice and upgrade, one other possible way to mitigate the issue is from the server side.

Cause

This vulnerability has many facets and this article presents only an overview. More details are available in the external links at the end.

Notes:

• It is technically an attack against a single browser, not the server. The most likely goal of an attack is to retrieve an encrypted session cookie in order to hijack a user's session.
   
• While a "practical" attack has been demonstrated, it is not a simple attack. It involves man-in-the-middle network access in conjunction with a certain amount of control over the user's browser to have it make repeated requests with content under the attacker's control, as well as heavy real-time computing power. The attack vector was known previously but not considered usable.
   
• The attack applies only to CBC (cipher block chaining) algorithms as implemented in SSL 3.0 and TLS 1.0. The streaming cipher RC4 is not vulnerable, and newer versions of TLS implement CBC in ways that are resistant to this attack. However, some cryptographers consider RC4 weaker than the CBC algorithms (AES and DES), while implementation of TLS 1.1+ is uncommon.
   
• Browser (and component) makers are taking steps to close the vectors that allow attackers the kind of access needed and implement TLS 1.1+.

Resolution

As this is a browser-side attack, you have these options to mitigate the possibility of an attack:

Require TLS 1.1+

If available, you can specify that only TLS 1.1+ ciphers be used by your server with the SSLCipherSuite directive (more about directives in the next section). It is not good enough to just enable TLS 1.1+ as an option alongside TLS 1.0/SSL 3.0, as it is fairly easy for a MITM to force a protocol downgrade to an available vulnerable protocol.

Note: Most browsers do not implement these protocols and would be unable to access sites requiring the newer protocols. This is only an option where you either control the browsers/clients or do not care if the site is unavailable to incompatible browsers. It is also only an option with OpenSSL 1.0.1 and greater (which is beta and not included in any VMware releases at time of writing).

Use the RC4 cipher

You can specify which ciphers your server will allow or prefer. The RC4 cipher is a stream cipher and is not vulnerable to this attack. However, there has been some debate about its strength and security. It is up to you to determine whether it suits your needs.

To allow only RC4 ciphers for your SSL server, you can specify the allowed ciphers with the SSLCipherSuite directive in your SSL configuration:

SSLCipherSuite !aNULL:!ADH:!eNULL:!LOW:!EXP:!SSLv2:RC4+RSA

This allows only a very limited set of ciphers. RC4 is widely implemented, but if some users have disabled it, they are unable to access your site. A less restrictive strategy might be to prefer RC4 but allow others. To do this, add the SSLHonorCipherOrder directive (which ignores the browser's preference of cipher in favor of the server ordering):

SSLCipherSuite !aNULL:!ADH:!eNULL:!LOW:!EXP:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:ALL
SSLHonorCipherOrder on

SSL connections use RC4 unless the browser does not support it, in which case the handshake falls back to other strong ciphers.

Reduce the lifespan of the SSL session

The BEAST attack involves repeated requests on the same SSL session to progressively decrypt plaintext over a span of minutes. This attack is disrupted by lowering the session life, forcing a new SSL handshake more often. Reducing the session life may mean a decrease in performance, but lowering the default SSLSessionCacheTimeout (5 minutes) to 30 seconds, or even lower, should not be too severe. However, it is up to you to determine the impact for your specific situation.

Additional Information

This vulnerability was discovered and reported publicly by field researchers. For more information, visit the vulnerability report and related links there, including both succinct and detailed information about the vulnerability.

As a further note, if an attacker has MITM access to a browser's traffic (as is necessary to exploit this vulnerability), BEAST is probably the most difficult available exploit to implement. Other vectors include SSL stripping and mixed-scripting. Consider prioritizing mitigation of these more likely exploits before BEAST. One standard to address these concerns is HSTS.

For further details and security analysis of the RC4 cipher by RSA, You can find a variety of opinions on the safety of RC4. For example, Google prefers RC4 for their secure servers while the FIPS standard categorically excludes it.