Other than requiring more server resources, are there any disadvantages of disabling RC4 from being using by an Apache webserver? My primary concern is preventing access from older browsers.

closed as too broad by RoraΖ, schroeder, Steve, Iszi, M'vy May 20 '15 at 10:08

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    check SSL labs on the topic of RC4. in short there is no reason to still support it as all browsers that support no better Key exchange are End-Of-Life. – LvB May 18 '15 at 12:58
  • I agree with the @dr01 that you should not care about older browsers, they are called older because a reason, just tell your users that if they want to use your service they should upgrade to newer system/browsers (why someone don't that is beyond me, they don't even have to pay for that) – Freedo May 18 '15 at 19:42
  • @Freedom some web apps do not work on newer browsers. I know a few companies that require IE 8 max to run their product. – schroeder May 19 '15 at 3:23
  • AIUI if you want to support IE (or anything else that uses the windows built in SSL/TLS stack) on windows XP you essentially get to chose between RC4 and 3DES with a maximum protocol version of TLS 1.0. So you get to pick your poison. BEAST attack or RC4 weaknesses. – Peter Green Nov 14 '15 at 3:44

Disabling RC4 completely would be great in an ideal world, but unfortunately we don't live in an ideal world. If you do disable it, certain mobile and embedded devices may not be able to communicate with you. Keep in mind that IE on Windows XP can only use RC4 because the underlying cryptographic API (CAPI) on the system doesn't have AES.

As for the risk, the RC4 bias attacks are generally considered to be relatively infeasible due to the requirements - somewhere in the order of a few billion requests. While this is clearly not good, it's also very hard to do anything practical with.

I would currently, as of May 2015, recommend the following:

  • Enable TLS 1.2 with AES-GCM, ChaCha20-Poly1305, AES-CBC, and RC4 cipher suites.
  • Enable TLS 1.1 with AES-CBC and RC4 cipher suites.
  • Enable TLS 1.0 with RC4 cipher suites (avoid CBC block ciphers in TLS 1.0 due to BEAST)
  • Disable SSLv3 and earlier.
  • Configure your cipher suite order preferences to have the AES-GCM and ChaCha20-Poly1305 suites at the top.
  • Prefer cipher suites with DHE / ECDHE key exchange over RSA / DSA key exchange to promote ephemeral key exchange.

Note that this is subject to change - you should check for up-to-date information in future.

In such a configuration, all but the very oldest browsers (i.e. anything post-90s) should work just fine, and modern browsers will use the strongest possible protocol and ciphers.

  • Side note: when I say XP can "only" use RC4, that's a simplification, as it also supports DES, which is arguably better in some respects if you use it as part of 3DES. However, I don't recommend 3DES in TLS 1.0 (the only protocol it would make sense to add it to for compatibility) due to BEAST and the meet-in-the-middle attack against 3DES. – Polynomial May 18 '15 at 13:49
  • Re. last bullet: What is "DSA key exchange"? Does this exist? – StackzOfZtuff May 18 '15 at 15:57
  • @StackzOfZtuff Sure. DSA long-term keys can be stored in certificates and used for the key exchange, just like RSA. – Polynomial May 18 '15 at 16:03
  • Huh. The OpenSSL 1.0.2's "ciphers" command only shows me "Kx=ECDH/ECDSA" as the only KX with DSA in it. Is that the one you mean? – StackzOfZtuff May 18 '15 at 16:07
  • @StackzOfZtuff Yes. ECDSA is the Elliptic Curve variant of DSA. Keep in mind that this is not the same as ephemeral. Unfortunately different implementations make it confusing, but the generally accepted format is to use the -E suffix (e.g. DHE) to signify ephemerality, and the EC- prefix (e.g. ECDH) to specify that it's an Elliptic Curve variant. If it's both elliptic curve and ephemeral, you'd use both: ECDHE. – Polynomial May 18 '15 at 16:14

I think you're asking the wrong question. To me, "How much will my users be inconvenienced?", is far less important than "How sensitive is the information on this server?", or "How much would I care if it got hacked?".

Hardening a system usually leads to some inconvenience. The level of inconvenience you're willing to endure (and inflict on your users) should depend on how valuable the data is that you're trying to protect. In other words, the more valuable a target you are, the more likely it is that a hacker will spend the resources to break your RC4.

  • 1
    I'm not sure that your advice holds in all situations - many very important web applications and web services are only used by legacy systems which do not support AES, but only DES and RC4. In such cases, disabling RC4 would prevent access from these devices. It's not all about how important the data is - there are also environmental factors. – Polynomial May 18 '15 at 13:45
  • @Polynomial Fair point, I will soften. – Mike Ounsworth May 18 '15 at 13:46

RC4 has been proven to be broken so is probably a sensible thing to disable it from a webserver.

You shouldn't bother to keep it on just to provide access to obsolete web browsers - after all, they're called obsolete for a reason, and giving the visitor incentives to upgrade his old browser is good.

  • I understand it to be broken, however, have no known threats at this time. Will an obsolete browser be totally unable to communicate? What browsers will experience this? – user1032531 May 18 '15 at 13:32
  • I appreciate your insight, but from a marketing perspective, don't agree. – user1032531 May 19 '15 at 4:11
  • 1
    I understand your situation, nevertheless be careful when you lower security at the expense of marketing, and always evaluate risk/benefits. – dr01 May 19 '15 at 7:29

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