Copyright © 1999 IDS Software.
All rights reserved.
November, 1999.
This article will introduce techniques for making a JDBC connection through a HTTPS proxy server. The IDS JDBC Driver is the only JDBC driver in the market that offers this firewall access capability. However, some of the topics discussed here are also useful to other Java applet developers who have to deal with client-side firewall issues.
The focus of this discussion is how a downloaded applet can make a JDBC connection to an IDS Server across the client-side firewall. A Java applet on a public Web site can be downloaded and run by client computers inside their own firewall protected networks. The only way for an applet to create a network connection to a server on the open Internet 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.
In a related article, "Firewall Access in Java Applets", we talked about how a Java applet can make a network connection to a server using JDK's built-in ability to connect through a SOCKS proxy server. The advantage of a SOCKS proxy connection is that it is persistent, just like a regular socket connection. The condition for this solution is that a SOCKS proxy server is running on the client-side firewall. Unfortunately, in reality SOCKS proxy servers are not as widely deployed as HTTP proxy servers.
IDS JDBC Driver also offers the option of connecting to the IDS Server via HTTP Tunneling. This feature uses standard Java API classes to make HTTP connections to the IDS Server. The browser's Java VM automatically handles HTTP connections through a HTTP proxy server if it is so setup. The disadvantage of HTTP Tunneling is that the connection is non-persistent. The actual network link is opened and closed repeatedly. Therefore, the performance is not as good as a regular socket connection.
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 Internet access to internal computers. For software applications, this kind of policing is done by proxy servers.
At the minimum, a proxy server must relay HTTP requests in and out of the firewall to offer Internet access to computers inside the private network (or intranet). This allows intranet users visit regular Internet Web sites with an URL starting with "http://". There is another kind of Web sites call secure Web sites with an URL starting with "https://". Secure Web sites are very common in areas like e-Commerce and on-line banking, because communication privacy is paramount. The following are two examples of both types of Web sites:
A regular Web site: http://wellsfargo.com/ A secure Web site: https://banking.wellsfargo.com/
When visiting a secure Web site, an Internet browser first establishes a secure communication protocol with the secure Web server, then begin transmitting and receiving the actual data. Such secure communication protocol is called Secure Socket Layer (SSL). The cryptographic technologies in SSL prevent network eavesdroppers from reading and altering the communications between the client computer and the server.
If your computer is behind a firewall, the proxy server must also handle HTTPS request for you to visit a secure Web site on the Internet. However, there is one significant difference between a proxy server processing HTTP requests and HTTPS requests. For HTTP requests, the proxy server is able to parse the communication content and exercise a lot more discretion on policing the traffics, including dropping the connection at the appropriate time (a proxy server always assumes HTTP connections are non-persistent).
On the other hand, the proxy server will not be able to decipher HTTPS connections because of encryption, so it has no choice but to relay the data intact and cannot drop the connection unless the client and or the server desires so. Another "secret" of HTTPS proxy connections is that the actual client/server communication need not to be encrypted or involve SSL, even though this type of connection is often called SSL Tunneling. Again, this is because the proxy server assumes the subsequent communication will not be readable. The ability to create a persistent connection and free of the interference of the proxy server is what we want to exploit here.
An Internet browser has its own proxy server setting in order to access the Internet inside a private network. For the IDS JDBC Driver to connect to the IDS Server using the HTTPS proxy, four conditions are required:
To verify the first condition, users behind a firewall can simply visit a secure Web site with an URL starting with "https://". If it is successful, then this condition is met. Otherwise, either the proxy server is not configure to allow HTTPS connection, or the Internet browser is not properly configured.
In Microsoft Internet Explorer, the proxy setting for HTTPS is: View - Internet Options - Connection - [x]Access the Internet using a proxy server - Advanced - Secure. For Netscape Communicator, the setting is: Edit - Preferences - Advanced - Proxies - [x]Manual proxy configuration - View - Security. Internet Explorer has another option called "[ ]Use the same proxy server for all protocols." Selecting this option if the same proxy server can handle all protocols, which is often the case.
How Java applets obtain proxy server settings is browser specific. Here, we present a fully implemented Java class ProxyProperties.java that works in both Internet Explorer (3.02 or higher) and Netscape Communicator (4.0 or higher). This class is a subclass of java.util.Properties. When instantiated, it contains the following set of properties (property names are case sensitive):
| Property Name | Comment |
| socksProxyHost | SOCKS proxy server settings |
| socksProxyPort | |
| http.proxyHost | HTTP proxy server settings |
| http.proxyPort | |
| https.proxyHost | HTTPS proxy server settings |
| https.proxyPort | |
| ftpProxyHost | FTP proxy server settings |
| ftpProxyPort |
Download the ProxyProperties class and source code here.
We will not discuss the detail of how this class works. Although experience Java developers will have no trouble understanding the mechanism from the source code. The following is an example of how to use this class with the IDS JDBC Driver:
Driver drv = new ids.sql.IDSDriver();
Properties info = new ProxyProperties();
String host = info.getProperty("https.proxyHost");
if (host != null) {
info.put("proxy_type", "4"); // SSL Tunneling
info.put("proxy_host", host);
info.put("proxy_port", info.getProperty("https.proxyPort"));
try {
// Netscape Communicator requires this call
PrivilegeManager.enablePrivilege("UniversalConnect");
}
catch (Throwable e) {}
}
Connection conn = drv.connect(url, info);
Normally, we use a java.util.Properties instance to pass connection properties to a JDBC driver. In the above example, we use the ProxyProperties instance directly, because it is a sub-class of Properties. If property "https.proxyHost" exists, the program sets the corresponding proxy properties recognized by IDS JDBC Driver. When the connect() method is call, the driver will establish a connection through the HTTPS proxy (also known as SSL Tunneling).
As mentioned earlier in "2. Proxy Server and HTTPS", the actual communication of HTTPS proxy connection need not to be encrypted or use SSL. Therefore, this technique can be used in both IDS Server Lite and IDS Server with Secure JDBC.
Java applets using the ProxyProperties class must be signed with a digital signature. The ProxyProperties class accesses the client computer's local resources, such as system registry and browser configuration file, to obtain the proxy server settings of the browser. These operations are regarded as security risks for the client and are normally prohibited by the browser's Java VM. If the applet is signed with a digital signature, the browser will use a GUI dialog to inform the user about the creator of the applet and ask the user whether to grant the applet access to local resources. If the user grants such privilege(s), security related operation performed by the applet later will be successful. Otherwise, those operations will fail.
Although proxy servers will not police the content of HTTPS connections, most proxy server do limit the destination host TCP/IP port number to be either 443 or 563. Port 443 and 563 are the default port numbers of secure Web servers and secure news servers respectively. It makes sense to run IDS Server on the secure Web server port number to allow IDS JDBC Driver clients to connect via HTTPS proxy servers. More importantly, since it is not possible to predict or demand how client-side firewalls are configured, you can only accommodate the most restricted client-side environment.
You may set the IDS Server port number in the "Port" setting in the IDS Server configuration file "idss.ini". If there is already a secure Web server running on the same machine as the IDS Server, you can use port 563 for IDS Server to avoid port conflict.
Firewall access is one of the most difficult issues of Java applet development and deployment, especially for applets that require network connections other than HTTP. The IDS JDBC Driver's ability to connect to an IDS Server via a HTTPS proxy servers provides an unique and high performance way to deploy JDBC enabled Java applets to firewall protected clients.
IDS Server Version 3.2.1 or later contains an Java applet example that demonstrate the use of the techniques discussed in this article. Please download and install the IDS Server evaluation. Then use your browser to visit the IDS Server Home Page and select JDBC Applet Example.
Last modified: November 2, 1999.