At CloudFlare we spend a lot of time thinking about the best way to keep our customers’ data safe. Despite recent troubles, HTTPS is still the best way to deliver encrypted content for the web. As the threat landscape changes we try to keep up with best practices with respect to which cryptographic primitives we use.
We recently removed support for RC4 for browsers using TLS 1.1+. Now we are removing RC4 as the preferred cipher. Servers behind CloudFlare will prefer AES-based cipher suites for all HTTPS connections and only use RC4 as a cipher as a last resort. We believe this is the right choice for the safety and security of our customers.
Why change now?
Let’s go back to 2011; most browsers supported the TLS 1.0 protocol and the preferred cipher was AES-CBC. Servers and consumer computers running the Intel Sandy Bridge chipset with hardware AES support were just being rolled out. RC4 was an old cipher in its twilight. Little did we know, RC4 would soon return to prominence.
In September 2011, Thai Duong and Juliano Rizzo discovered an attack called BEAST against TLS. It allowed an attacker with a privileged position in the network and the ability to trick a user into going to a malicious site the ability decrypt data when any CBC-based cipher was chosen. This was a big deal and the community decided to try its best to solve the problem. The immediate workaround was to get servers to prefer a non-CBC cipher and the only good widely-supported candidate was RC4. Most server operators (including CloudFlare made the change and pretty soon most of the Internet was back to being encrypted using RC4.
The environment today is much different. In the years after BEAST, client-side mitigations were introduced at the operating system level on Windows and OS X. It was also fixed in browsers that do not rely on the system to provide TLS, including Firefox and Chrome. Now, all major browsers support the TLS 1.2 standard in which AES-CBC is not vulnerable to BEAST and most support a new cipher mode called AES-GCM which is not vulnerable to any known attacks. Over 43% of the traffic to CloudFlare sites is now over TLS 1.2. Creaky old RC4 is looking more and more unnecessary as a workaround for the BEAST problem.
Not only is RC4 increasingly irrelevant as a BEAST workaround, there has also been mounting evidence that the RC4 cipher is weaker than previously thought. In 2013, biases in RC4 were used to find the first practical attacks on this cipher in the context of TLS. This attack does not fully break the cipher but it does suggest there are more weaknesses to be discovered in the 27 year old stream cipher. Confidence in the long-term security of RC4 is at an all-time low.
Publicly known attacks are often discovered years in advance by government researchers. If the public is five years away from breaking a cipher, the intelligence community probably has already broken it. In part because of this, Bruce Schneier (and others) believe that it’s plausible that RC4 encryption can currently be removed in real time by a three letter agency with the right resources. RC4 is likely not the best way to encrypt our data if we want it to be private for years and years.
Active attacks vs passive attacks
All said, this leaves the Internet community with a tough decision to make. Do we drop RC4 or keep it as the preferred cipher? The options are:choose AES-CBC and leave older clients vulnerable to BEAST attacks;choose RC4 and risk that encrypted communication can be decrypted in real time, or decrypted retroactively once RC4 is broken.
One way to think about this is in terms of forward secrecy. We previously brought up the topic of forward secrecy in terms of key establishment. If you make a TLS connection to a server using an RSA handshake, and someone gets hold of your private key, they can go back and decrypt your conversation. Using a forward secret handshake like ECDHE can protect you from this, as long as your encryption algorithm is strong. However, if your underlying encryption algorithm is weak, an attacker can decrypt your conversation no matter which handshake you use. That’s the risk with RC4. When someone eventually breaks it, all previous conversations can be decrypted.
BEAST is different in that it has to be done in real time. The attacker needs to inject packets into the network during the encrypted conversation. It is also a “noisy” attack in that it results in a lot of suspicious network traffic. It requires both tricking someone into going to a malicious site and owning a privileged place in the network to pull off. It is not the kind of attack that can be used en masse against the entire Internet. If the cipher you choose is secure, then BEAST can’t be used to retroactively decrypt your conversation. If RC4 is broken, then up to 50% of the traffic of the Internet over the last two years is at risk.
It is widely believed that AES-CBC is a secure cipher for the long term, unlike RC4. Choosing AES-CBC provides our customers with long-term forward secrecy, even if it could open them up to a rarely executed noisy active attack if they are using an out of date browser and OS. Choosing RC4 exposes our customers’ data to any government who has advanced enough cryptographic techniques to break it. When faced with this choice, we would rather protect our customers from long term threats by choosing AES-CBC. Experts agree, it’s time to move on from RC4.
Who uses RC4?
Instead of just removing RC4 altogether, we decided first to lower the priority of the RC4 cipher suites on our servers. Typically in HTTPS, the client lets the server know which cipher suites it supports, from which the server picks their favorite. By putting RC4 last in terms of server preference, we will only choose RC4 if it the client does not support anything else. The following chart shows what happened when we changed our cipher preferences.
The purple and brown lines show the percentage of connections to one of our servers using RC4 cipher suites. When we changed our cipher preferences (around 18:00 on this chart), these two lines went down to nearly zero. The green and red lines show the replacement AES cipher suites. The blue line at the bottom mostly represents visitors using Internet Explorer on old versions of Windows XP, which does not support AES.
After this change, only 0.0009% of visitors connected to our servers with RC4. Taking a close look at the data we found some interesting results. A small proportion of visitors were using candybar phones running custom mobile-optimized browsers. Most logs we saw were from individuals using browsers that support AES but who manually changed their cipher suite selections to remove it. They might be doing this to optimize client performance. Although AES is faster than RC4 on recent Intel processors, RC4 is less computationally intensive on old computers and mobile devices that do not have cryptographic acceleration in hardware. We do not recommend choosing RC4 for performance reasons just yet as there are interesting new alternatives coming soon, watch this blog for more details.
Now what?
Every major browser and operating system has a workaround for BEAST, so we recommend that users upgrade their browsers and operating systems to take advantage of the added protection TLS 1.2 with AES-GCM provides. We no longer recommend RC4 as a suitable server-side mitigation for the BEAST attack. When RC4 is finally broken (if it isn’t already), data sent through sites on CloudFlare will be safe for the long term.
For browsers connecting with TLS 1.2 we will prefer AES-GCM, for older TLS versions we will prefer AES-CBC. Here is our new recommended cipher suite list:
EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
If you do need to support the 0.0009% of visitors who require RC4, try the following:
EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:EECDH+RC4:RSA+RC4!MD5;
We have updated the CloudFlare Internet-facing SSL cipher configuration GitHub page to reflect this change.