Channels

Services

Mozilla considers disabling Java in Firefox

The Firefox developers are currently discussing whether to disable Oracle's Java plug-in as a potential workaround for the recently disclosed SSL/TLS vulnerability. The Java plug-in is the component that enables attackers to exploit the vulnerabilities presented by Juliano Rizzo and Thai Duong last week – the two researchers demonstrated how the cookies of arbitrary web pages can be reconstructed despite being sent via encrypted connections.

For their chosen-plaintext attack on the Cipher-Block Chaining (CBC) mode that tends to be used with TLS, Rizzo and Duong have to bypass the browser's Same Origin Policy (SOP) so that they can communicate with servers outside of, for instance, the Java applet's domain.

Although the purpose of SOPs is to prevent exactly that, a previously undisclosed bug in Java appears to enable attackers to do so regardless. In the Firefox developers' opinion, the onus is therefore on Oracle to solve the Java problem first. However, Oracle has so far failed to respond, which has prompted the developers to consider releasing an update that disables all Java plug-ins for security reasons. This would, however, disable some user functionality: examples given by the Director of Firefox Engineering, Johnathan Nightingale, include Facebook's video chat and various Java-based corporate applications.

Google has implemented a different solution in the developer version of Chrome: to make it more difficult for attackers to control the plain text to be injected, packets are split up, and an empty one is added before each packet. Reports received so far suggest that this approach has caused problems with very few sites. However, it is not known when Google will incorporate the workaround into the stable version of Chrome.

Microsoft's recommended solution is that users switch from TLS 1.0 to TLS 1.1, but this approach requires that servers support TLS 1.1 as well – and, so far, only a few servers offer this support. Some Firefox developers think that this wouldn't solve the problem anyway, because Java uses its own TLS stack – and this stack only supports the vulnerable TLS 1.0.