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.

user1032531
  • 313
  • 2
  • 3
  • 11
  • 2
    check [SSL labs](https://www.ssllabs.com/) 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 03: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 03:44

3 Answers3

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.

Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • 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
  • @Polynomial As your answer has been accepted would it be worthwhile including a note that IETF are 'against' the use of RC4 longer term (RFC7465), so that if future readers refer to your response (out of context) there is at least some possibility that they will not blindly implement RC4 without first considering their requirements? – R15 May 18 '15 at 16:30
  • @R15 Good point, though just mentioning RC4 alone may not be sufficient due to future developments. I've just put a generic note in there. – Polynomial May 18 '15 at 16:54
  • and @StackzOfZtuff: **RSA** cert (and key) can be used alone to encrypt the premaster (no PFS), or to authenticate either DHE or ECDHE; integer **DSA** can be used to authenticate DHE (never alone) but for hysterical raisins it is spelled **DSS** in the suite name, and openssl displays it in Au= but not Kx=; **ECDSA** can be used to authenticate ECDHE (never alone). – dave_thompson_085 May 24 '15 at 00:39
  • @dave_thompson_085: Yep. I know. I'd just never refer to it as "DSA key exchange". (Only "DSA *authenticated* key exchange".) – StackzOfZtuff May 24 '15 at 06:38
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.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • 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
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.

dr_
  • 5,060
  • 4
  • 19
  • 30
  • 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 04: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 '15 at 07:29