5

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.

Improve this question
4
  • 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, 2015 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, 2015 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, 2015 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, 2015 at 3:44

3 Answers 3

Reset to default
6

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.

Improve this answer
9
  • 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, 2015 at 13:49
  • Re. last bullet: What is "DSA key exchange"? Does this exist?
    – StackzOfZtuff
    May 18, 2015 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, 2015 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, 2015 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, 2015 at 16:14
3

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.

Improve this answer
2
  • 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, 2015 at 13:45
  • @Polynomial Fair point, I will soften.
    – Mike Ounsworth
    May 18, 2015 at 13:46
1

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.

Improve this answer
3
  • 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, 2015 at 13:32
  • I appreciate your insight, but from a marketing perspective, don't agree.
    – user1032531
    May 19, 2015 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.
    – dr_
    May 19, 2015 at 7:29

Not the answer you're looking for? Browse other questions tagged .