BEAST smothered by security blanket

7.0 was converted to final this morning and I'm pulling down 8 beta 1 for initial conversion as we speak. This will require more work than 7 because Mozilla committed a number of 10.5/10.6-specific widget changes which will need to be rewritten for 10.4, but I'm pretty confident this is possible. You'll be the first to know.

A number of people have privately asked me whether TenFourFox is susceptible to the BEAST SSL attack revealed over the weekend. This rather startling hack was able to decrypt a Paypal cookie sent over SSL, allowing the attacker to assume the identity of the logged-in user. It should come as no surprise that 1) the Mozilla security team has been discussing this (along with representatives from Google, which uses the Netscape-originated Network Security Services library also) for several months, and 2) as shipped, TenFourFox is not vulnerable. Notice that I said "as shipped." The exploit demonstrated by Rizzo and Duong used a Java applet to do the server thrashing needed to get the key out, and TenFourFox disables all plugins including the Java Embedding Plugin, so the applet cannot run. It may be possible to do something similar in Flash (though such code has not yet? surfaced), but obviously this doesn't ship enabled in TenFourFox either, and the version of WebSockets in Firefox 7 and TenFourFox 7 cannot be used to trigger this exploit.

Even with plugins, Java and/or other suitable footholds available, the SSL flaw in question is not trivial to exploit: not impossibly hard nor prohibitively expensive, but neither is it simple, quick or easy. An attacker must have control of the network the victim is using (such as a compromised or open wireless link), and must be fast enough to spy on the connection and manipulate the victim's browser to try combinations on the server the victim is accessing before the session terminates. Under the optimal conditions of the demonstration the "victim" was pwned in about two minutes; real world assaults will undoubtedly require significantly more time. It is also possible for servers to immunize themselves against the attack by negotiating ciphers that are not vulnerable to the flaw Rizzo and Duong are taking advantage of; RC4/ARC4 is one such cipher and Google is using it already on its services.

The best solution is to leave TLS 1.0 behind, but for a variety of reasons this has yet to happen, and perhaps this will be the impetus to change to a safer, later TLS version. Once a final fix is decided upon for NSS, there may or may not be a 7 chemspill; we'll follow Mozilla's lead here. A similar fix will be included in Classilla, which is technically vulnerable but hard to exploit because OS 9's MRJ is mercifully too old and Flash 7 does not support sockets of the type required.