The following discussion and Java network leak tests were performed using Mozilla Firefox 2.0.0.11 and the Sun Java Runtime Environment (JRE) 1.6u3 on both Windows and Linux. Early or later versions may behave differently.
Java applets (and LiveConnect) can be used to determine certain information about a user's connection to the Internet by establishing socket connections back to an origin server. This leakage of network information is unacceptable to people that wish to mask their true network location through the use of Tor or other proxies.
Java has two primary methods of establishing socket connections: sockets and HTTP URL connections. Connections can be established back to the origin server on any port. For users behind proxy servers, proxy configuration is performed through the Java Control Panel (for the 1.6 versions, javacpl.exe on Windows and jcontrol on Linux). However, both the socket and URL classes expose methods that allow network proxy settings to be bypassed.
The first method is through the Socket class. The socket can be created to explicitly bypass a proxy using the Proxy.NO_PROXY static class. According to the documentation, the JRE should use the socksProxyHost system property when creating connections. However, there is no indication that is actually happening.
The second method is to use the URL class to construct a specific network URLConnection instance. This class does appear to respect the network proxy settings (e.g., "http.proxyHost"). The proxy can be overridden by specifying Proxy.NO_PROXY to the openConnection method.
The following is a collection of Java network leakage tests for Firefox. There are tests for sockets and URL connections both with and without proxies.
Java 6 added additional methods to the NetworkInterface class. These methods allow the Java applet to retrieve the hardware address of all network interfaces. Depending on the environment, this may or may not be considered a significant information leak.
Both applet and LiveConnect versions are included. The 1.6u3 JRE introduced changes that were meant to address DNS rebinding attacks. Java applets cache the IP address and hostname of the codebase, but classes created through LiveConnect don't have any codebase cached. As a result, sockets created through LiveConnect will attempt to verify certain additional DNS settings (e.g., A and PTR linkage, "auth" records) before establishing the connection. These checks results in extra DNS traffic and possible failure in connecting.
Note: Windows users may encounter an error "Can't get Java class name usingjava.lang.Class.getName()" when running the LiveConnect tests. This probably means that the JVM in the browser has crashed and all Firefox windows must be closed and restarted.
Download the source to the Java leakage tests (sig).
| Applet | |||||
| LiveConnect |