CC BY 2.0 image by Stuart Heath

Our OpenSSL configuration is freely available on our Github account here as are our patches to OpenSSL 1.0.2.

We strive to stay on top of vulnerabilities as they are announced; in this case no action was necessary as we were already protected by decisions to eliminate cipher suites and upgrade software.

We are also pro-active about disabling protocols and ciphers that are outdated (such as SSLv3, RC4) and keep up to date with the latest and most secure ciphers (such as ChaCha-Poly, forward secrecy and elliptic curves).

Over a year ago, we disabled RC4 for connections for TLS 1.1 and above because there were more secure algorithms available. In May 2014, we deprecated RC4 by moving it to the lowest priority in our list of cipher suites. That forced any browser that had a good alternative to RC4 to use it. Those two changes meant that almost everyone who was using RC4 to connect to CloudFlare sites switched to a more secure protocol.

Back in May, we noted that some people still needed RC4, particularly people using old mobile phones and some Windows XP users. At the time, 4% of requests using RC4 came from a single phone type: the Nokia 6120.

At the time, we noted that roughly 0.000002% of requests to CloudFlare were using the RC4 protocol. In the last 9 months, that number is halved and so, although some people are still using RC4, we have decided to turn off the protocol. It's simply no longer secure.

The remaining users are almost all on old phones and Windows XP (those two groups make up 80% of the RC4-based requests). But we are still seeing some connections from SSL-intercepting proxy software that's using RC4. To repeat what we said in May:

Digging into the User-Agent data for the US, we see the following web browser being used to access CloudFlare-powered sites using RC4:

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36

That's the most recent version of Google Chrome running on Windows 7 (you can see the presence in Windows 7 in the chart above). That should not be using RC4. In fact, most of the connections from Windows machines that we see using RC4 should not be (since we prioritize 3DES over RC4 for older machines).

It was initially unclear why this was happening until we looked at where the connections were coming from. They were concentrated in the US and Brazil and most seemed to be coming from IP addresses used by schools, hospitals, and other large institutions.

Although the desktop machines in these locations have recent Windows and up to date browsers (which will not use RC4) the networks they are on are using SSL-based VPNs or firewalls that are performing on-path attacker monitoring of SSL connections.

This enables them to filter out undesirable sites, even those that are accessed using HTTPS, but it appears that the VPN/firewall software is using older cipher suites. That software likely needs updating to stop it from using RC4 for secure connections.

Since May, that situation has remained largely unchanged: there are some institutions doing SSL-interception (probably for IDS or policy enforcement reasons) that use RC4 for outbound connections, and many apparent individuals running software that does the same.

We've been continually tracking what's happening in the academic community around RC4 attacks and the slow death of RC4 as people switch from old devices to newer ones.

With both a decline in RC4 connections to CloudFlare and whispers of another, easier attack on RC4 in the academic community, we've decided the time is right to disable RC4 completely.

To understand who needs RC4 I delved into our live logging system and extracted the User-Agent and country the visitor was coming from. In total, roughly 0.000002% of requests to CloudFlare use the RC4 protocol. It's a small number, but it's significant enough we believe we need to continue to support it for our customers.

Requests to CloudFlare sites that are still using RC4 fall into four main categories: people passing through proxies, older phones (often candy bar), other (more on that below) and a bucket of miscellaneous (like software checking for updates, old email programs and ancient operating systems).

Examining data for a 59 hour period last week showed that 34.4% of RC4-based requests used RC4-SHA and 63.6% used ECDHE-RSA-RC4-SHA. RC4-SHA is the oldest of those; ECDHE-RSA-RC4-SHA uses a newer elliptic curve based method of establishing an SSL connection. Either way, they both use the RC4 encryption algorithm to secure data sent across the SSL connection. We'd like to stop supporting RC4 altogether, because it is no longer believed to be secure, but continue to offer it for the small number of clients who can't connect more securely.

If you ever need to know the details of an SSL cipher you can use the openssl ciphers command:

$ openssl ciphers -tls1 -v RC4-SHA RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1

which shows that RC4-SHA uses RSA for key exchange, RSA for authentication, RC4 (128-bit) for encryption and SHA1 for message authentication.

Similarly,

$ openssl ciphers -tls1 -v ECDHE-RSA-RC4-SHA ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1

shows that the same encryption, authentication and message authenitication are used as RC4-SHA but the key exchange is made using Elliptic Curve Diffie Hellman.

One of the reasons RC4 is used for encryption is its speed. RC4 is a very fast encryption algorithm and it can be easily implemented on a wide variety of hardware (including phones with slow processors and even on 8-bit systems like the Arduino). After all, RC4 dates back to 1987.

The core of RC4 is the following algorithm:

i := 0 j := 0 while GeneratingOutput: i := (i + 1) mod 256 j := (j + S[i]) mod 256 swap values of S[i] and S[j] K := S[(S[i] + S[j]) mod 256] output K endwhile

It generates a pseudo-random stream of numbers (all 8-bit numbers in the range 0 to 255) by doing simple lookups in a table, swapping of values and addition modulo 256 (which is very, very fast). The output of that algorithm is usually combined with the message to be encrypted byte-by-byte using some fast scheme like an XOR.

The following short video shows the RC4 algorithm in action. It's been restricted to 32 values rather than 256 to fit it nicely on the screen but the algorithm is identical. The red stream of numbers at the bottom shows the pseudo-random stream output by the algorithm. (The code for this animation is available here; thanks to @AntoineGrondin for making the animated GIF).

[

](http://staging.blog.mrk.cfdata.org/content/images/rc4.gif)

So, RC4 is fast, but who's still using it? To answer that I looked at the HTTP User-Agent reported by the device connecting to CloudFlare. There were 292 unique User-Agents.

Firstly, lots of people using older "candy bar" style phones. Phones like the Nokia 6120 classic which was released in 2007 (and is the phone with the greatest number of RC4 requests to CloudFlare sites: 4% of the RC4-based requests in the measurement period), the Lemon T109 or the Sony Ericcson K310 which was released in 2006.

And, of course, it's not all older telephones being used to visit CloudFlare-powered web sites. There are old browsers too. For example, we've seen the now ancient iCab 2.9.9 web browser (it was released in 2006) and we've seen it being used running on a 68k based Macintosh (last sold by Apple in 1996).

Another source of RC4-only connections is older versions of Adobe AIR. AIR is often used for games and if users don't update the AIR runtime they can end up using the older RC4 cipher.

Yet another source is stand-alone software that makes its own SSL connection. We've seen some software checking update servers using RC4-secured connections. The software makes a connection to its own update server using HTTPS but the available ciphers are limited and RC4 is chosen. The command-line program curl was used to generate 1.9% of RC4-based requests to CloudFlare sites (all done with versions dating to 2009).

There's also quite a bit of older Microsoft Internet Explorer around including Internet Explorer 5.01 (which dates back to 1999!). Here's a breakdown of Internet Explorer versions connecting using RC4:

Looking at Windows tells a similar story of older version of the operating system (except for the presence of Windows 7 which is explained below) with lots of Windows XP out there:

I sampled connections using RC4 to see which countries they came from. The following mapping shows the distribution of RC4-based connections across the world (the darker the more RC4 was used).

From the map you can see that in Brazil, India, and across central Africa RC4 is still being used quite widely. But you'll also notice that the coloring of the US indicates that a lot of RC4 is in use there. That seems like a surprise, and there's an extra surprise.

Digging into the User-Agent data for the US we see the following web browser being used to access CloudFlare-powered sites using RC4:

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36

That's the most recent version of Google Chrome running on Windows 7 (you can see the presence in Windows 7 in the chart above). That should not be using RC4. In fact, most of the connections from Windows machines that we see using RC4 should not be (since we prioritize 3DES over RC4 for older machines).

It was initially unclear why this was happening until we looked at where the connections were coming from. They were concentrated in the US and Brazil and most seemed to be coming from IP addresses used by schools, hospitals and other large institutions.

Although the desktop machines in these locations have recent Windows and up to date browsers (which will not use RC4) the networks they are on are using SSL-based VPNs or firewalls that are performing proxy monitoring of SSL connections.

This enables them to filter out undesirable sites, even those that are accessed using HTTPS, but it appears that the VPN/firewall software is using older cipher suites. That software likely needs updating to stop it using RC4 for secure connections.

You can check the strength of your browser's SSL configuration by visiting How's My SSL. If you get a rating of "Probably Okay" then you're good. If not make sure you have the latest browser version.

Also be sure to update to the latest version of Adobe Flash (if you use it) and Adobe AIR (if you use it).

If you are using an old phone that uses RC4 consider not using it for secure web browsing. RC4 is widely believed to be broken.

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.

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.

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.

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.

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.

The BEAST vulnerability itself had already been fixed in TLS v1.1 a few years before, but in 2011 the adoption of TLS v1.1 was virtually non-existent and web server administrators (and companies like CloudFlare) started preferring RC4 over AES-CBC ciphers in order to mitigate the attack.

Fast-forward to 2013 and attacks on RC4 have been demonstrated; that makes the preference for RC4 problematic. Unfortunately, at the time, TLS v1.1 and above still weren't very popular, which meant that we had to make a choice between either the mitigation of BEAST or the RC4 attack.

Since then, all modern browsers have started supporting TLS v1.2, which means that in theory we could support RC4 only for connections using TLS v1.0 in order to protect against BEAST attack and use AES-GCM or AES-CBC for connections using TLS v1.1 and above in order to protect against RC4 attack. Unfortunately, open-source web servers (and OpenSSL) don't allow for such fine-grained control over which ciphers should be supported for which protocol version.

To make that possible, we are releasing a patch for OpenSSL which disables RC4-based cipher suites for connections using TLS v1.1 and above, while leaving them there to protect users still using TLS v1.0.

--- a/ssl/s3_lib.c
+++ b/ssl/s3_lib.c
@@ -3816,6 +3816,11 @@
                        (TLS1_get_version(s) < TLS1_2_VERSION))
                        continue;

+               /* Disable RC4 for TLS v1.1+ */
+               if ((c->algorithm_enc == SSL_RC4) &&
+                       (TLS1_get_version(s) >= TLS1_1_VERSION))
+                       continue;
+
                ssl_set_cert_masks(cert,c);
                mask_k = cert->mask_k;
                mask_a = cert->mask_a;

SSL Labs have updated their testing to penalize the use of RC4 on TLS v1.1 and v1.2 connections as detailed here. If a site allows RC4 with TLS v1.1 or v1.2 then the following warning will appear in the SSL Labs report:

SSL Labs have introduced warnings that will lower a web site's score. Warnings are given for a lack of forward secrecy, missing secure renegotiation, or the use of RC4 on TLS v1.1 and v1.2. Web sites are also heavily penalized for using key sizes below 2048 bits.

Customers of CloudFlare using our SSL options will get an A or A+ rating with no warnings from SSL Labs.

You can download the patch here.

Broadly there are three ways we use TLS: to handle HTTPS connections from web browsers visiting web sites that use CloudFlare, to make HTTPS connections from our network of datacenters to our customers' web servers, and internally within our network.

This week, news of a new type of attack against the RC4 cipher used for some TLS connections has made us reevaluate (once again) all our use of TLS and specifically which ciphersuites we are using.

This blog post gives some background on TLS and ciphersuites, the most recent attack and how we are configuring our systems to keep our customers (and their customers) as safe as possible.

When two computers want to communicate securely using TLS, one of them (referred to as the client) connects to the other (the server) and they enter a negotiation about what encryption method to use. Central to that communication is an agreement between client and server on which ciphersuite will be used. The ciphersuite specifies precisely the type of encryption that will be used between client and server.

For example, when you visit a web site such as https://cloudflare.com/ using HTTPS a TLS connection is established between your web browser and the CloudFlare web server. Your web browser starts the TLS connection by telling the web server which ciphersuites it supports: it tells the web server which types of encryption it is able to use.

The list of available ciphersuites varies from browser to browser and from version to version. The University of Hannover has a little web site that will show you which ciphersuites your web browser supports. To use it just visit https://cc.dcsec.uni-hannover.de/.

For my browser, the latest version of Google Chrome, the list of suites is as follows. The order gives the web browser's preference for ciphersuites. For example, it would prefer to use

ECDHE-ECDSA-AES256-SHA 

instead of

ECDHE-RSA-AES256-SHA.

ECDHE-ECDSA-AES256-SHA ECDHE-RSA-AES256-SHA DHE-RSA-CAMELLIA256-SHA DHE-DSS-CAMELLIA256-SHA DHE-RSA-AES256-SHADHE-DSS-AES256-SHA ECDH-RSA-AES256-SHAECDH-ECDSA-AES256-SHARSA-CAMELLIA256-SHA RSA-AES256-SHAECDHE-ECDSA-RC4128-SHA ECDHE-ECDSA-AES128-SHA ECDHE-RSA-RC4128-SHA ECDHE-RSA-AES128-SHA DHE-RSA-CAMELLIA128-SHA DHE-DSS-CAMELLIA128-SHA DHE-DSS-RC4128-SHA DHE-RSA-AES128-SHA DHE-DSS-AES128-SHA ECDH-RSA-RC4128-SHA ECDH-RSA-AES128-SHA ECDH-ECDSA-RC4128-SHA ECDH-ECDSA-AES128-SHA RSA-SEED-SHA RSA-CAMELLIA128-SHA RSA-RC4128-SHA RSA-RC4128-MD5 RSA-AES128-SHA ECDHE-ECDSA-3DES-EDE-SHA ECDHE-RSA-3DES-EDE-SHA DHE-RSA-3DES-EDE-SHA DHE-DSS-3DES-EDE-SHA ECDH-RSA-3DES-EDE-SHAECDH-ECDSA-3DES-EDE-SHA RSA-FIPS-3DES-EDE-SHA RSA-3DES-EDE-SHA

Each web server will have a similar list of ciphersuites and during the TLS handshake (at the start of a TLS connection) the client and server will agree on a ciphersuite that they both understand taking into account the order of preference of the client and server.

When I connect to https://cloudflare.com/ my browser and the CloudFlare web server agree to use ECDHE-RSA-RC4128-SHA. That cryptic string has a lot of information in it. It explains how the browser and server will exchange or agree onencryption keys and how the actual web browsing I do will be encrypted.

It breaks down as follows:

ECDHE means that the client and server will agree on encryption keys using Ephemeral Elliptic Curve Diffie-Hellman.

RSA means that the client will verify that the key is valid using the RSA algorithm to communications.

RC4128 means that the actual encryption of my web browsing session will be performed using the RC4 algorithm with a 128-bit key (that's the key that the client and server will have agreed using ECDHE-RSA).

And finally SHA means that the SHA algorithm will be used for securely hashing parts of the TLS messages.

CloudFlare's server configuration for TLS ciphersuites is set in nginx (which we use extensively) with the following configuration command:

ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-RC4-SHA: ECDHE-RSA-AES128-SHA:AES128-GCM-SHA256:RC4:HIGH: !MD5:!aNULL:!EDH:!CAMELLIA; ssl_prefer_server_ciphers on;

(Note that a previous version of this blog post had the wrong configuration caused by yours truly copy/pasting the wrong thing).

That results on the server offering the following ciphersuites (you can check this yourself using the SSL Labs Report):

ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-RC4128-SHA ECDHE-RSA-AES128-CBC-SHA RSA-AES128-GCM-SHA256 RSA-RC4128-SHA ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-CBC-SHA384 ECDHE-RSA-AES256-CBC-SHA RSA-AES256-GCM-SHA384 RSA-AES256-CBC-SHA256 RSA-AES256-CBC-SHA ECDHE-RSA-3DES-EDE-CBC-SHA RSA-3DES-EDE-CBC-SHA ECDHE-RSA-AES128-CBC-SHA256 RSA-AES128-CBC-SHA256 RSA-AES128-CBC-SHA

The CloudFlare server's preference is ECDHE-RSA-AES128-GCM SHA256 but unfortunately it is not widely supported. Yet. I'll come back to that ciphersuite later. So, my browser and the server agreed to use the server's second preference, ECDHE-RSA-RC4128-SHA.

You'll notice that we've configured the CloudFlare server to prefer ciphers that use ECDHE. That's because, unlike the ciphers that start with RSA, they offer forward secrecy. To understand forward secrecy it's best to start by understanding systems that don't offer it, such as RSA.

When using RSA, the server's public key is used to encrypt a secret created by the client, the web browser. Because the server has the private key it can read the secret and both the client and server then know a shared secret that they can use for encryption. But the server's public RSA key is part of the server certificate and is typically very long lived. It's not uncommon for the same public key to be used for months or years (the current CloudFlare RSA key isn't set to expire until December 5, 2013). That creates a potential problem: if an SSL server's private key were to leak or be stolen all connections made in the past using that key would be vulnerable. It would be enough that someone had recorded your SSL connections: with the private key they could all be decrypted.

But forward secrecy with ECDHE means a fresh public key is created for every single connection. That means that an adversary would need to break the key for each connection individually to read the communication. And the keys are ephemeral: the server forgets them when connections are done. So there's nothing to leak.

So, we've prioritized those ciphers because they offer a higher level of long term security for people contacting CloudFlare sites.

I mentioned above that the ciphersuite that CloudFlare prefers is ECDHE-RSA-AES128-GCM-SHA256 and that ECDHE is preferred because it offer forward secrecy. The next part of the ciphersuite is RSA. In the ECDHE scheme that's just used to prove the identity of web server, and not to secure the connection, so the concerns above about leakage of the private key don't apply.

The next part is AES128-GCM. This is the cipher that will be used to encrypt the actual HTTP requests and responses encrypted in the TLS connection. This particular cipher is using AES with a 128 bit key in Galois/Counter Mode. Unfortunately, this very strong cipher is only part of TLSv1.2 which is not widely supported by web browsers. CloudFlare has it configured ready for the day when it is supported because it is very secure.

Since TLSv1.2 isn't widely supported, the two popular ciphers used to secure the data sent across a TLS connection are RC4 and AES (in CBC mode). Both have flaws and both have attacks that could be used against them. Very recently a new attack against RC4 was announced that could allow an attacker to recover parts of the original HTTP message (such as a cookie value) when RC4 is used.

The CBC mode ciphers have attacks called Lucky-13 which we've discussed before and BEAST which we've also talked about.

Because BEAST and Lucky-13 both attack CBC-based ciphers, CloudFlare decided in the past to prioritize the use of the other cipher:

RC4. Unfortunately, the latest attack goes after RC4. So now both the popular ciphers have published flaws. The sooner browser vendors move to TLSv1.2 and away from RC4 and AES in CBC mode the better.

The new RC4 attack is based on biases in the RC4 keystream. To understand how the attack works it's necessary to understand a little of how RC4 works.

RC4 operates by generating a pseudorandom stream of bytes of data called the keystream. These bytes are XORed with the information to be encrypted and the result is transmitted. For example, suppose that the word SECRET is to be sent using RC4.

In ASCII, SECRET is the following six hexadecimal numbers:

S E C R E T 83 69 67 82 69 84

Suppose that RC4 generates the following six bytes in the keystream:

85 B8 D6 6B C7 51

To encrypt SECRET the keystream is XORed with the word SECRET byte by byte and the result, 06 D1 B1 E9 AE D5, is transmitted.

        S  E  C  R  E  T

Message: 83 69 67 82 69 84 Keystream: 85 B8 D6 6B C7 51 XOR ----------------- Ciphertext: 06 D1 B1 E9 AE D5

(This XOR technique dates all the way back to 1919 with the Vernam Cipher; read the Wikipedia article for a basic introduction to the use of XOR in ciphers. RC4 itself, of course, is much more recent.)

The exact pseudorandom sequence that RC4 generates depends on the key used. As long as both client and server have the same key they can generate the same keystream and perform the same set of XOR operations to encrypt and decrypt data. That's because XOR is its own inverse: if you do Z = X XOR Y and then do Z XOR Y you get back to X.

So, when 06 D1 B1 E9 AE D5 is received on the other side it performs the same XOR operation with the same keystream sequence to recover the original message.

Ciphertext: 06 D1 B1 E9 AE D5 Keystream: 85 B8 D6 6B C7 51 XOR ----------------- Message: 83 69 67 82 69 84 S E C R E T

But it's vital that the keystream be random so that an eavesdropper can't obtain any useful information from the ciphertext. If the random stream contained biases (such as some numbers that came up more often than others) it would be possible to use probability to predict what the original, unencrypted message was.

That's what the latest RC4 attack shows. Specifically, there are biases in the first 256 bytes of keystream generated by RC4. Those first bytes are likely to be used to encrypt the start of an HTTP request and may include sensitive information such as a cookie used for logging into a web site.

The attack works by causing the same request to occur over and over again (for example, using a piece of JavaScript to contact the same web site repeatedly). On each connection the same request (with the same cookie) will be encrypted with RC4. A different key is used each time which results in a different keystream, but over many encryptions any biases in the keystream will show up as certain numbers appearing in the ciphertext more or less often than others (because some numbers appeared more often than others in the keystream).

The numbers that make up the RC4 keystream should be totally random. So if the same message, such as the word SECRET above, is encrypted over and over again with RC4 the resulting ciphertexts should be totally random: the probability of each number between 00 and FF appearing should be the same. If you encrypted SECRET over and over again with RC4 and counted the number of occurrences of 00 to FF in the ciphertext they should be roughly equal. Just as if you roll a fair die over and over again and count how many times the numbers 1 to 6 appear they should be equal.

Unfortunately, the researchers have discovered that the first 256 bytes of the keystream are not completely random and over time a pattern emerges.

For example, here's their chart showing the probability of each number appearing as the first number produced in the RC4 keystream. This should be completely flat with each number being equally probable. It's not. That means that if the same message were encrypted over and over again it would be possible to determine (with a certain probability) what the original first character was.

With many repeated tests, just as rolling a loaded die many times would show which numbers come up most often, the attack can see which ciphertext numbers come up most frequently and match that pattern to the pattern in the keystream. From that a simple XOR can reveal the original message.

And the same authors describe another attack based on biases in adjacent numbers in the keystream that works at any point, not just in the first 256 bytes.

So both of the widely supported ciphers have faults. These faults are exploitable by attackers under the right conditions; they are not theoretical attacks, but they are hard to pull off. Nevertheless, CloudFlare will be happy when we can move away from RC4 and CBC-based ciphers and put Lucky-13, BEAST and others behind us.

While CloudFlare has to wait for browser makers to implement the latest and safest cryptography, we don't have to wait for any of our internal systems.

CloudFlare uses TLS internally extensively (and between CloudFlare software components like Railgun) and has recently done an audit of all uses of TLS to ensure that the best ciphers are in use. And so for situations where CloudFlare controls both the client and server we are deprecating use of TLSv1.1 and switching to TLSv1.2 with ECDHE-RSA-AES128-GCM-SHA256 as the current cipher of choice.

As the world of cryptography and TLS changes CloudFlare will keep updating its systems to keep them at the forefront of the available research.