BEAST mitigation on a Cisco ACE 4710 load balancer

Question

We are looking to mitigate BEAST (and similar) on our Cisco ACE appliance (running version A4(2.0)), which is the 'endpoint' for a handful of load-balanced services. Some of these service still run with SHA1-signed certificates (although we are working on having our clients test with SHA2-signed certs).

The ACE allows us to create a parameter-map to prioritise the ciphers it supports (with priority 10 being the most-preferred and 1 being the least-preferred), but I am not fully aware of the intricacies of each cipher suite.

Would the following be a reasonable mitigation (essentially prioritising CBC-based ciphers lower, so as to prefer the non-CBC ciphers)? Are there any on this list I really shouldn't be accepting? We are obviously aiming to still be as compatible as reasonably possible.

Note that we are not trying specifically to meet PCI compliance, just attempting to 'do the right thing' (although if any of the below would violate such, it would be helpful to know in case it comes up in the future)

parameter-map type ssl PMAP_SSL_CIPHERS
  cipher RSA_WITH_RC4_128_SHA            priority 6
  cipher RSA_WITH_RC4_128_MD5            priority 6
  cipher RSA_EXPORT1024_WITH_RC4_56_SHA  priority 6
  cipher RSA_EXPORT1024_WITH_RC4_56_MD5  priority 6
  cipher RSA_EXPORT_WITH_RC4_40_MD5      priority 6
  cipher RSA_WITH_AES_256_CBC_SHA        priority 2
  cipher RSA_WITH_AES_128_CBC_SHA        priority 2
  cipher RSA_WITH_3DES_EDE_CBC_SHA       priority 2
  cipher RSA_WITH_DES_CBC_SHA            priority 2
  cipher RSA_EXPORT1024_WITH_DES_CBC_SHA priority 2
  cipher RSA_EXPORT_WITH_DES40_CBC_SHA   priority 2

score 3 · Answer 1 · answered Apr 11 '13 at 12:10

The simplest way to mitigate BEAST is to do nothing at all. BEAST is a client attack. Servers can "protect" clients by enforcing the use of RC4-based cipher suites even if the client states that it prefers some CBC cipher suites. However, all recent Web browser versions include workarounds which make them immune to BEAST, namely the 1/n-1 split; and the server has never been vulnerable to begin with.

Also, BEAST relies on the ability to inject in the client some hostile Javascript which can send arbitrary binary requests to an external host; this requires a hole in the Same Origin Policy. The two holes which were used in the original BEAST demo have been patched (one used a bug in Java, the other an old draft version of WebSockets).

Therefore, is BEAST is still a concern for you, then your browser is madly out-of-date and has quite a lot of other, more urgent vulnerabilities. Update it ASAP. As a by-product, it will fix any BEAST-related worries.

score 2 · Answer 2 · answered Apr 12 '13 at 08:40

Given that:

current browsers (including IE6) have patches to work around BEAST,
it's a difficult attack to perform anyway, and
there has been progress in attacking RC4 of late,

preferring RC4 as a measure to defeat BEAST seems of questionable utility. It is certainly not a clear-cut win, and shouldn't be represented as a necessary basic security measure (as some scanners do spuriously, to give themselves something to complain about).

However, it would definitely be worth getting rid of the FIPS-compliant-but-unconscionably-weak EXPORT and single-DES ciphers. Certainly preferring RSA_EXPORT_WITH_RC4_40_MD5 over RSA_WITH_AES_256_CBC_SHA is not at all sensible!

BEAST mitigation on a Cisco ACE 4710 load balancer

2 Answers2