Copyright © 1998-1999 IDS Software.
All rights reserved.
Rev. 2, September 1999
The ability to create network connections in Java applets is a very powerful feature that most other Web based applications do not have. It allows the deployment of versatile client/server applications over the Internet. However, the existence of firewalls presents a bit of a challenge to Java applets that use persistent network connections (i.e. TCP/IP socket) between the client and the server(s).
A firewall can be view as a combined hardware/software system that links two isolated networks, usually a private network and the Internet. A firewall polices the traffics between the two networks, blocking access from the Internet to the private network, while providing controlled Internet access to internal computers. For software applications, this kind of policing is done by a proxy server.
In a client/server model, a firewall may exist on the server-side, the client-side or both. Here, server-side firewall means the server is in a private network, but Internet clients are granted access to this server. To grant such external access is relatively easy and often transparent to both client and server applications. The focus of this article is not server-side but client-side firewall access.
Client applications like Java applets can be downloaded and run by computers that are in their own firewall protected networks. If a Java applet creates a network connection to a server, the server (e.g. the Web server deploys the applet) is usually outside the client-side firewall. The only way to create such connection is by going through the client-side proxy server. The difficulty here is that the client can be anonymous, so the applet has no prior knowledge of the client-side firewall and its proxy server.
The Java class encapsulates a TCP/IP network connection is java.net.Socket. It represents a generic network connection, free of any particular software level protocol like HTTP, SMTP, FTP, SSL, etc. Most Web proxy servers perform software protocol level policing, monitoring and caching by interpreting the network data stream of the designated protocol. Obviously, this kind of proxy server is not suitable for a generic connection created by java.net.Socket.
SOCKS is a new emerging proxy server protocol developed by NEC. It is software protocol independent. After the initial handshake and authorization process, a SOCKS proxy server do not care about the content of the data stream. This is perfect for proxying java.net.Socket connections.
Since Java Development Kit 1.0.2, a java.net.Socket instance has the ability to connect to a remote host through a SOCKS proxy server. The condition that triggers this feature is the existence of the System property "socksProxyHost" and optionally "socksProxyPort". Although, the JDK documentation does not clearly spell out this feature, programmers can view the actual implementation in the JDK source file "java/net/PlainSocketImpl.java".
An Internet browser has its own proxy server setting in order to access the Internet from inside a firewall protected private network. Whether Java applets can use the JDK built-in SOCKS proxy feature depends on whether the browser properly convey its SOCKS proxy server setting to its Java VM (i.e. setting the System property "socksProxyHost" and "socksProxyPort"). Here is how each popular browser fairs in this matter:
| Browser | Support SOCKS proxy in java.net.Socket |
| Internet Explorer 3.02 | No, but possible |
| Internet Explorer 4.0.x and 5.0 | Yes |
| Netscape Communicator 4.0.x, 4.5PR1 | No, but possible |
| Netscape Navigator 3.0.x | No |
| HotJava Browser | Yes |
The requirement for Internet Explorer 4.0 and HotJava is that there is a SOCKS proxy server running on the client-side firewall, and the SOCKS server address and port number is set in the browser's proxy configuration. Then all java.net.Socket connections to remote hosts are transparently established via the SOCKS proxy server.
Internet Explorer 3.02 does properly set the two System properties for SOCKS proxy. Unfortunately, the "PlainSocketImpl.java" file was compiled by an erroneous compiler, which prevents "PlainSocketImpl.class" from detecting that System property "socksProxyHost" is set. The solution is either upgrade to IE 4.0 or just upgrade to Microsoft VM for Java 2.02 or 3.0. Upgrading the Java VM alone keeps all IE 3.02 features except that the Java VM will be identical to that of IE 4.0 (JDK 1.1 compatible).
The problem with Netscape Communicator is that it does not convey its proxy server settings to its Java VM by setting the System property "socksProxyHost" and "socksProxyPort". However, with the aid of digital signatures, applets can overcome this deficiency.
Communicator saves most of its configuration, including proxy settings, in the file "prefs.js". Each user of Communicator on the same machine has a separate copy of "prefs.js" in the user's home directory. The solution is for the applet to seek out the proxy server settings then set the relevant System properties. To do all that, the applet must be signed with a digital signature.
The following link contains an applet that demonstrates how this may be implemented. In the source file "HttpTrace.java", the most relevant code is the very last method setNavigatorProxyProperties(). This method first locates the "prefs.js" file, loads all preferences into a Properties instance, then sets the appropriate System properties. Note that this applets also works in IE 4.0 and HotJava 1.1, but the setNavigatorProxyProperties() method has no effect.
| HTTP Trace Applet | http://www.idssoftware.com/demos/trace.html |
| (see next topic) | http://64.82.84.216/demos/trace.html |
The setNavigatorProxyProperties() method maps four sets of Communicator preferences to the corresponding System properties. The set of System properties used here is identical to those used by IE 4.0 and HotJava.
| Communicator Preference | Java System Property |
| network.hosts.socks_server | socksProxyHost |
| network.hosts.socks_serverport | socksProxyPort |
| network.proxy.http | http.proxyHost |
| network.proxy.http_port | http.proxyPort |
| network.proxy.ssl | https.proxyHost |
| network.proxy.ssl_port | https.proxyPort |
| network.proxy.ftp | ftpProxyHost |
| network.proxy.ftp_port | ftpProxyPort |
The SOCKS protocol implemented in JDK is Version 4. One of the problem in SOCKS V4 is that it only accept the remote host address in numeric IP address format, for example, 198.80.94.70. It does not accept domain name address such as www.idssoftware.com. This restriction requires the client to be able to resolve the domain name of the remote host into IP address. It is not uncommon that in some private networks internal clients cannot resolve Internet domain names.
Although, the constructor of java.net.Socket accepts domain name addresses, but JDK always tries to resolve the domain name to IP address, which is also required by SOCKS V4. If your machine cannot resolve Internet domain names, JDK will throw an java.net.UnknownHostException.
There are a number of solutions. For the above HTTP Trace Applet, if you select
the second hyper-link, the getHost() method in the applet will automatically pick
up the numeric IP address of the IDS Software
web server. This is because the HTML page is referenced by IP address instead of
domain name, and the getCodeBase() method of the Applet class reflects that.
Another solution is to explicitly specify the hosting server's IP address in a <PARAM>
tag and call getParameter() in the applet to retrieve it.
A revised SOCKS Version 4A and the current SOCKS V5 do accept domain name as remote host address. Currently, none of these two protocols are implemented in JDK or Internet browsers.
Application developers may implement their own client side SOCKS V4A or SOCKS V5 and use the JDK built-in SOCKS V4 as a fall back. The requirement is that the applet must have the necessary privilege to obtain the proxy server settings (e.g. System property "socksProxyHost", etc.). This usually requires the applet to be signed.
Another software protocol independent proxy protocol is called SSL Tunneling. This protocol is supported by many Web proxy servers such Netscape Proxy Server and Microsoft Proxy Server 2.0. Similarly, developers have to implement the protocol on their own.
The IDS JDBC Driver is a pure Java application that implements all four proxy protocols: SOCKS V4, SOCKS V4A, SOCKS V5, and SSL Tunneling. JDBC applications can explicitly specify the proxy server address, port number, proxy authentication ID and password, and which protocol to use to connect to IDS Server. Please refer to the JDBC Applet Example in the IDS Server evaluation.
To successfully run Java applets that create network connections across a client-side firewall, one may rely on the JDK built-in SOCKS V4 proxy connection feature. This requires the installation of a SOCKS proxy server on the client-side firewall. Further, the client browser must have its proxy server configuration properly setup. Special coding and digital signature are required to overcome a deficiency in Netscape Communicators.
Last modified: September 16, 1999