Hacker News Reader

Comment by rythie | Hacker News Reader

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

View on HN

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.

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.

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

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.

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 .

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

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.

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

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.

Reply on news.ycombinator.com