I feel bad for the sysops who're scheduling 3am maintenance windows on production TLS services for the edge case this presents. God damn security researchers!
Except that's not going to happen because for now the only viable alternative to RC4 in TLS is AES in CBC mode, which suffers from its own problems (BEAST and Lucky 13). It's really a question of which is worse, and that's not so easily answered.
The RC4 attacks currently require the client being attacked to make millions of connections to the legitimate server. However, this could be done over a long period of time and the webserver may not even log an error for each attempt.
Under the right circumstances, BEAST can be exploited with a real-time practical number of connections. It was demoed on stage. Those circumstances don't include every browser configuration, but they're not very extraordinary.
The circumstances BEAST relies on involves a rapidly diminishing set of browsers. As I understand it, BEAST is less of a motivator for RC4 than Lucky 13.
To be honest the writing has been on the wall for RC4 for a while and there are viable alternatives. People should have at least been prioritizing other TLS suites before this news.
Have you read other articles relating to TLS security over the last several months? Keeping in mind BEAST and Lucky 13 and browser support, I would ask you which ones you would prioritize over RC4 and why?
I am well aware of these attacks as I am actively involved in discussions at CloudFlare about how we best protect our customers. Clearly browser support for things like AES GCM and TLS 1.2 is the limiting factor.
However, TLS is not only used between browser and web server. We can use better ciphers in situations where both ends can be controlled.
