Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm using a Verisign Extended SSL cert which is piped downstream by nginx running the default cipher suite config.

This results in a 256 bit encrypted connection.

However, since it's a CBC method, should I be concerned about a BEAST attack?

The nginx manual offers the following suggestion to drop back to RC4 (which doesn't appear to be affected by that particular attack):

ssl_ciphers RC4:HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

That's fine, but it drops the encryption back to 128 bit, too.

Is it preferable to opt for 256 bit that's vulnerable to BEAST, or 128 bit that's not (but may be vulnerable to other attacks)?

share|improve this question
up vote 1 down vote accepted

No, there aren't supported RC4 ciphers of a greater key length than 128 bit.

The use of this cipher as the current "best practice" might open the door a bit wider for a brute force attack against the shorter key, but is the lesser of two evils at the moment.

share|improve this answer
Thanks Shane, makes sense. – Lee Benson Jul 25 '12 at 9:17

Instead of playing around with ciphers, you should do what's commonly recommended:

  • discontinue the use of TLS 1.0 and use TLS 1.1 or TLS 1.2 instead
  • or use the OpenSSL "empty TLS record" feature which has been there to counteract this type of attack even before BEAST was discovered and is enabled by default:


Disables a countermeasure against a SSL 3.0/TLS 1.0 protocol vulnerability affecting CBC ciphers, which cannot be handled by some broken SSL implementations. This option has no effect for connections using other ciphers.

share|improve this answer
from your link: "Safari, Chrome and Mozilla Firefox do not support TLS 1.1 and 1.2.". Wouldn't that disqualify 80% of my visiting traffic, or am I missing something? Re: SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS, isn't that a client-side fix? – Lee Benson Jul 24 '12 at 13:02
@Lee I don't know what your visiting traffic looks like. And the "empty TLS record" workaround is a server-side feature which is enabled by default in OpenSSL (though sometimes disabled by the admins due to compatibility issues by setting SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS) – the-wabbit Jul 24 '12 at 19:44
I appreciate your answer and granted, you don't know my visiting traffic - but it's usually a safe bet that Safari, Chrome and Firefox would factor into just about any site, no? As such, I probably wouldn't recommend anyone go rush out and disable TLS 1.0 just yet! – Lee Benson Jul 24 '12 at 20:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.