[ccollins]

From the article, to find out what your website is doing:

openssl s_client -host HOSTNAME -port 443

I ran this for my own website and a few bigger websites

  openssl s_client -host www.gusta.com -port 443 (My site, hosted on Heroku)
  Cipher    : DHE-RSA-AES256-SHA
  
  openssl s_client -host www.google.com -port 443  
  Cipher    : RC4-SHA 
  
  openssl s_client -host www.airbnb.com -port 443  
  Cipher    : AES256-SHA
  
  openssl s_client -host www.facebook.com -port 443
  Cipher    : RC4-MD5
  
  openssl s_client -host www.paypal.com -port 443
  Cipher    : AES256-SHA

  openssl s_client -host www.amazon.com -port 443
  Cipher    : RC4-MD5

[rythie]

Presumably Amazon, Facebook and Google are using RC4 for speed reasons, though it's not really thought to be secure anymore.

[tptacek]

RC4 is fine in SSL/TLS.

Nobody likes it, but until relatively recently, the AES ciphersuites were all CBC mode, which means they burned a couple bytes of padding for every record.

RC4 is also faster than AES, which was, until very recently, an issue for server performance.

We have AES-CTR ciphersuites now, but I'm not sure how widely deployed they are.

[briansmith]

The padding for AES cipher suites isn't a significant performance issue. The per-record IV in TLS 1.1 and later, the overhead of the tls-cbc.txt workaround for earlier versions, and/or the extra block(s) of encryption required for HMAC-SHA-2-based cipher suites are bigger performance issues.

RC4 is faster than AES on older processors. On the current generation of Intel server processors, AES is faster because of AES-NI.

AES-GCM cipher suites should be even faster yet on those processors, but they are not widely implemented. Also, I wouldn't be surprised to see more interesting papers being published about weaknesses in the GMAC function in the near future. (Note: I don't have any knowledge of upcoming papers; I am guessing there will be some based on the recent paper regarding the discovery of unexpected weak keys in GMAC.) Nonetheless, I suspect that NSS will implement them because they are part of the NSA Suite B profile for TLS and some NSS developers want a complete implementation of that.

[newman314]

I was under the impression that RC4-MD5 was no longer recommended but RC4-SHA was okay (comparatively). Is this incorrect?

[yuhong]

The hash algorithm in TLS is HMAC-hash. Some uses of MD5 like secret suffix are now insecure (which is why usage of MD5 for certificate signing ended long ago), but HMAC is not one of them.

[benblack]

While I would certainly prefer to see the major players leading the way in adoption of AES by default, RC4-MD5 persists for at least 2 reasons:

1) Habit

2) As implemented/deployed in SSL, it still provides some security

RC4 has gotten a bad reputation in large part because of its poor application in WEP that resulted in keys being rapidly recovered by sniffing traffic. The Wikipedia entry is a good place to start http://en.wikipedia.org/wiki/RC4#Security (& numerous references for the original papers/pubs cracking various bits of RC4). The RSA response to RC4 concerns (from WEP) is worth reading, as well http://www.rsa.com/rsalabs/node.asp?id=2009 .

[newman314]

I just did a quick dig to see if browsers now allow the user to specify a preferred cipher but it looks like things have not progressed. Chrome for instance has marked a request as WONTFIX.

http://code.google.com/p/chromium/issues/detail?id=58833

[kronusaturn]

RC4 has known weaknesses, but it's still extremely difficult to crack when implemented correctly. Attackers want to go for your weakest point, which is almost certainly not RC4; typically it's far more difficult to crack RC4 than to steal your data by finding a SQL injection or buffer overflow, or simply breaking into your building.

[paulitex]

Is that so?

openssl s_client -host online.citibank.com -port 443

Cipher : RC4-MD5

openssl s_client -host www.bankofamerica.com -port 443

Cipher : RC4-MD5

[benblack]

Banks are unfortunately poster children for what not to do in this space, generally. The default cipher for google.com is RC4-SHA, and I can, if so inclined, force negotiation of AES-based ciphers by client config. Not so with Citibank (RC4-MD5, DES-CBC3-SHA, or DES-CBC-SHA) & BofA is only marginally better (RC4-MD5, RC4-SHA, AES128-SHA). To their credit, they are using 2048 bit RSA keys with short lifetimes and they have significantly improved their configurations from a couple of years ago when single DES defaults and 40-bit RC4 were all too common.