SSL, RC4, and Site Administrators

Tech @ FTC 2013-03-29

There’s been yet another report of security problems with SSL.  If you run a website or mail server, you may be wondering what to do about it.  For now, the answer is simple: nothing—and don’t worry about it.

First of all, at the moment there’s nothing to do.  You can’t invent your own cryptographic protocol; no one else would have a compatible browser.  Besides, they’re notoriously hard to get right.  In the very first paper on the topic, Roger Needham and Michael Schroeder wrote “Finally, protocols such as those developed here are prone to extremely subtle errors that are unlikely to be detected in normal operation. The need for techniques to verify the correctness of such protocols is great, and we encourage those interested in such problems to consider this area.”  Why do you think your design will be better than one that has been scrutinized for more than 15 years?

Some of the trouble in this latest breach is due to weaknesses in the RC4 cipher algorithm.  No one who works in cryptography was surprised by this report; it’s been showing cracks since at least 1997.  What’s new is that someone has managed to turn the weaknesses into a real exploit, albeit one that needs at least 224 and preferably 230 encryptions of the same plaintext to work.  (By the way, this is why cryptographers are so concerned about minor weaknesses: as Bruce Schneier is fond of noting, attacks always get better, they never get worse.)  Besides, ciphers are even harder to get right than protocols are.

The real reason not to worry, though, is that unless you’re being targeted by a major intelligence agency, this sort of cryptanalytic attack is very far down on the risk scale.  Virtually all attackers will look for unpatched holes, injection or cross-site scripting attacks, people who will fall for spear-phishing attacks, etc., long before they’ll try something like this.  The common attacks are a lot easier to launch; besides, the attackers understand them and know how to use them.

In the long run, RC4 has to be phased out.  I certainly wouldn’t start any new designs that depended on RC4’s characteristics or performance, but there are plenty of other algorithm possibilities today.  Vendors do need to ship web browsers and servers that support newer versions of SSL (formally known as TLS); weaknesses at the protocol level can’t always be fixed by patching code.  For now, though, stay up to date with your patches and software, and practice good security hygiene.  (And if you are being targeted by a major intelligence agency, you should talk to a major counterintelligence agency, not me…)