Home > Confidentiality, Encryption, Integrity, Security > Kicking RC4 out the door

Kicking RC4 out the door


I’ve been arguing with my web hosting company about their use of RC4.  Like many enterprise networks they aren’t consistent across all their servers with respect to available ciphers and such.  It appears that all customer servers support TLS_RSA_WITH_CAMELLIA_256_CBC_SHA and TLS_RSA_WITH_CAMELLIA_128_CBC_SHA, in addition to TLS_RSA_WITH_RC4_128_SHA (although the latter is preferred over the other two) but their backend controlling web servers only support RC4.  This is a problem if you are handling crypto (keys) (and other settings) over a weak encryption path to better secure your web service as you have essentially failed due to using the weak encryption to begin with.

So what’s wrong with RC4?

It’s been known for a while (years!) that RC4 is not a good encryption cipher.  It’s broken and there are several attacks that are available.  So why is it being used so frequently?  In a word: BEAST.  RC4 was the only stream cipher available that can combat BEAST and so it became the standard for all TLS connections.  It’s not clear which attack vector is worse: BEAST or the weak RC4.

In recent months most Internet browsers have implemented the workaround n/n-1 to fix the BEAST vulnerability.  With the fix in place it should, once again, be safe to use block ciphers and, thus, get better encryption ciphers (better protection).  There have been many people and organizations talking about the need to get rid of RC4 now since it is a bigger threat to web security.  Yesterday Microsoft released a security bulletin discussing the problem and urged all developers to stop using RC4.  (Oh yeah, and they also want to stop using SHA-1 as well.)  I usually think of Microsoft as trailing in the security field (lets face it, their products aren’t known for being secure ever since that whole network thing happened) so when they say that this mess with RC4 must stop it’s gotten to a point where we should have already done so.

So what are we waiting for?

I think, simply, we’re waiting for TLSv1.1 and TLSv1.2 to become mainstream.  It’s not as if these technologies have just popped up on our radar screens, however, (they’ve been out since April 2006 and August 2008, respectfully) but there has been slow adoption of the two flavors of TLS.  According to Microsoft, their products are ready for TLSv1.1 and TLSv1.2 (both IIS on and IE 11+).  Firefox supports up to TLSv1.2 in 25.0 but you have to manually turn it on (it’s for testing) and OpenSSL (used for Apache) should support TLSv1.2 in its 1.0.1e release.  It’s time to start pushing these better encryption mechanisms into operation… now.

Updates

What Google has to say on the subject.

About these ads
  1. DDD
    2013-11-13 at 21:01 EST

    The latest NIST recommendations go even further. Basically it’s TLS1.2/AES256/SHA512/GCM and elliptic curve Ephemeral Keys if you want to sell to government these days.

    My favourite new technology, though, is DANE rfc 6698. This should be mandatory, because the TTPs are the weak points, and I actually trust DNS integrity *more*

    • 2013-11-13 at 22:23 EST

      I’m hoping that we’ll be able to cover the Internet with TLSv1.2 here real soon.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 224 other followers