PolarSSL is now part of ARM Official announcement and rebranded as mbed TLS.

Calmly moving away from RC4

Introduction

RC4, also known as ARCFOUR or ARC4, was developed in the late 80's by Ron Rivest, and is still one of the most used ciphers in TLS. The first theoretical attacks on RC4 were uncovered in 1995, but more recently, in 2013, a group of researchers published an attack that is practical in some limited circumstances against RC4 used in TLS.

While this attack is not an immediate threat in most circumstances, it shows it's time to start deprecating RC4 before it's too late. As Bruce Schneier puts it, "There's no reason to panic here. But let's start to move away from RC4". There is a general agreement on this in the TLS community, reflected in the Qualys SSL/TLS Best Practices document and an upcoming IETF Best Current Practice document.

At PolarSSL, we want our users to be safe by default, so we are taking steps to deprecate RC4 without waiting for the IETF document to be finalised. However, we are also aware that RC4 is still widely used, and is sometimes the only available option to communicate with some peers (about 2% of servers in June 2014), so that removing RC4 support straight away would actually hurt some of our users.

So we came up with the following plan for calmly deprecating RC4, and we decided to share it so that you can prepare for the upcoming changes and provide feedback if needed.

The Plan

PolarSSL 1.3.7 (Released in May 2014)

In this release, the default priority list of SSL/TLS ciphersuites has been changed so that ciphersuites using RC4 come at the very end, right before the ciphersuite which are so weak that they are disabled by default at compile-time. The practical implications are:

  • Server-side. When the server preferences are used (which is the default), then an RC4 ciphersuite will never be selected except if it is the only option to communicate with the client.
  • Client-side. The server can choose to honor or disregard the client's preferences, so that it can still pick an RC4 suite if configured to do so.

A client that wants to avoid RC4 will need to remove it from the ciphersuite list using ssl_set_ciphersuites() and decide what to do if the handshake fails. A server that prefers to break handshakes than to use RC4 will need to do the same.

Also, it is obviously possible to permanently disable all RC4 ciphersuites at compile time by commenting #define POLARSSL_ARC4_C in config.h.

PolarSSL 1.3.8 (June / July of 2014)

A compile-time flag is provided with the effect that RC4 ciphersuites are excluded from the default list, but can still be re-enabled at runtime by using ssl_set_ciphersuites(). It is more convenient than calling ssl_set_ciphersuites() to enable all ciphersuites except the RC4 ones.

This flag is disabled by default in order to preserve compatibility within the 1.3.x branch.

PolarSSL 2.0 (Planned before end of 2014)

The compile-time flag introduced in 1.3.8 is now enabled by default. The practical implication is that RC4 will never be negotiated with any peer, on any side, unless explicitly asked by the developer at runtime.

However, it is still possible to enable RC4 at runtime in order to communicate with some peers that might still need it.

PolarSSL 3.0 (No date planned yet)

The whole RC4 module is now disabled by default at compile-time. Hopefully you don't need it any more since everyone has moved away from RC4 and towards better options. More realistically, it is still possible to enable it if you really need it, since it's only one #define and one call to ssl_set_ciphersuites() away.

Conclusion

We strive to reach a balance between security and interoperability considerations, and hope this plan provides a good way forward. As usual, if you have questions or suggestions for improvements, your feedback is welcome.

Like this?

Section:
Blog

Author:


Published:


Last updated:
Jun 26, 2014

Sharing:


Want to stay up to date?

To sign up for Mbed TLS news, log in to or create an Mbed account and update your marketing preferences.