27

It seems that the easiest way to protect users against the BEAST attack on TLS <= 1.0 is to prefer RC4 or even disable all other (CBC) cipher suites altogether, e.g. by specifying something like

SSLCipherSuite RC4-SHA:HIGH:!ADH

in the Apache mod_ssl configuration.

However, the problem with CBC seems to have been fixed in TLS >= 1.1; is there any way to (re)enable these ciphers for clients claiming to support TLS 1.1 or 1.2? There seems to be a workaround:

SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH

which does the trick by specifying cipher suites that are only available in TLS >= 1.1. That seems to have the side effect of preventing TLS >= 1.1 clients to use any of the "older" cipher suites.

Is there really no way to explicitly tell mod_ssl to use CBC mode ciphers for TLS >= 1.1, but only RC4 for SSL/TLS <= 1.0? That would seem to be an optimal combination of security and compatibility.

Andrei Botalov
  • 5,267
  • 10
  • 45
  • 73
lxgr
  • 4,094
  • 3
  • 28
  • 37
  • I am not aware of a single browser that should be used, that does not support TLS >= 1.1, so what exactly are you worried about? Do your users a favor and require them to use a secure browser. – Ramhound Jul 12 '12 at 11:38
  • 3
    Are you serious? TLS 1.1 will only be supported in the upcoming version 21 of Chrome and is not supported in Firefox, and I don't even want to begin to research the state of TLS 1.1 support on mobile devices. – lxgr Jul 12 '12 at 13:34
  • 1
    And Firefox doesn't support TLS 1.1 yet either. See [Mozilla bug 565047](https://bugzilla.mozilla.org/show_bug.cgi?id=565047). IE8 on Windows XP doesn't support TLS 1.1. Together, these 3 browsers account for a majority of browsers used today. – Stefan Lasiewski Jul 20 '12 at 00:06

3 Answers3

16

One way to mitigate BEAST is to do nothing. It so happens that though the vulnerability used in BEAST is still there, exploiting it is rather difficult. It requires the ability to do cross-domain requests, with a high level of control on the data which is sent in the request; in particular, it needs "binary" data. Duong and Rizzo did not find a way to map the attack on plain <img> tags (hostile Javascript which produces such tags, with an attacker-chosen path: the path gets in the request, but it is text-only). In their demonstration, they could use two cross-domain holes, one in a draft version of WebSockets, the other in the implementation of Java from Oracle. Both holes have since been fixed, therefore, right now, BEAST does not apply anymore (unless you did not update your browser for more than one year, in which case you probably have bigger problems).

Since relying on the non-existence of cross-domain vulnerabilities is, at best, flimsy, browser vendors have also included some extra countermeasures, with record splitting. When the browser wants to send a block of n bytes of data, instead of putting it in one SSL record, it splits it into two records, the first being very small. Record boundaries have no semantic significance in SSL/TLS, so you can do such splitting without changing the meaning. However, each record ends with a MAC computed over the record data and a sequence number, and using one key derived from the initial key exchange. This somehow acts as a pseudo-random number generator. Therefore, the small record "emulates" the random IV generation that makes TLS 1.1+ immune from BEAST.

Ideally, the split would be 0/n: a record with no data (but still with a MAC), followed by a record with the actual data. Zero-length records are allowed (as per the standard) but buggy client and server implementations do not tolerate them (in particular IE 6.0); instead, browsers use a 1/n-1 split, which is just as good for defeating BEAST, but also works with almost all existing SSL/TLS clients and servers. At least Chrome and Firefox have pushed it last year.

The good solution is TLS 1.1+ but even on SSL 3.0 and TLS 1.0, the BEAST issue can be considered as fixed, at least in the Web context. Therefore, use AES, and be happy.

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 2
    Most PCI scanning vendors consider BEAST a high-risk threat which will disqualify you for certification. So even though exploiting it is a low-probability low-reward proposition, fixing it becomes imperative for companies that need certification. – tylerl Nov 26 '12 at 01:16
  • @tylerl- as long as you have the mitigation documented and demonstrated, PCI requirements can be seen to be met. – Rory Alsop Nov 26 '12 at 08:06
10

OpenSSL has a mitigation for BEAST which has been enabled by default since 0.9.6d, so as long as your OpenSSL version is this version or later and you haven't set SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS there is no need to restrict ciphers or disable TLS 1.0.

mgorven
  • 596
  • 5
  • 11
0

My understanding is that TLS < 1.1 with any block cipher in CBC mode is vulnerable to BEAST. Again, to my understanding, your only options are to use TLS 1.1 or greater, or to use a stream cipher.

Or, of course, you could use a different protocol that isn't affected by BEAST, Like SSH :)

atk
  • 2,156
  • 14
  • 15