When it comes to the mitigation of the BEAST attack against SSL/TLS, the usual advice is to prioritize RC4 cipher suites in order to avoid CBC suites, which are vulnerable. In some cases, companies may even have to use RC4 suites exclusively. For example, I’ve recently heard of a case where a company was failed on its PCI compliance test because they had non-RC4 cipher suites enabled in their configuration.
When RC4 prioritization is discussed, people often seek assurance that RC4 is widely supported. Obviously, if you are going to disable a large number of cipher suites, you start to worry if the remaining suites are going to be sufficient for your user base. Until recently, I had no answer to those questions. Even though all major browsers support RC4 by default, there was no way to quantify the support. Further, some browsers allow users to turn off certain cipher suites, and we just didn’t know what the situation on the ground was.
About two months ago I re-enabled mod_sslhaf on the SSL Labs web server. This Apache module, a project of SSL Labs, records all cipher suites offered by clients. Today I looked at the results, curious to find out exactly how many of the SSL Labs clients supported RC4. I choose to compare the total number of unique IP addresses against the number of IP addresses that did not support TLS_RSA_WITH_RC4_128_MD5 (0x04) or TLS_RSA_WITH_RC4_128_SHA (0x05).
In about two months, SSL Labs saw 48,481 unique IP addresses. Only 45 of those — or 0.09% — did not support RC4. Looking at the user agent information, the clients not supporting RC4 seem to be largely those whose users decided to explicitly disable RC4 for one reason or another.
The usual disclaimer applies here: the sample is taken from the SSL Labs web site and may not apply to other sites. However, if the assumption that the only non RC4 clients are those where this cipher suite was disabled by their owners, you could argue that an average site will see an even smaller number of non-compatible clients.