Drawbacks of HTTP Tunneling

2. If that fails, it attempts to connect on port 80 of the firewall machine and send the request to a URL beginning with cgi-binjava-rmi.cgi. The interpretation of this URL is that the request will be forwarded to a program that interprets the HTTP request and forwards it, as an HTTP request, to the appropriate port on the server machine. Hence, to run the bank example using HTTP tunneling, we simply add another line to the application that launches the client: public class BankClient { public static void mainString[] args { try { RMISocketFactory. setSocketFactorynew sun.rmi.transport.proxy. RMIHttpToCGISocketFactory ; } catch IOException ignored {} new BankClientFrame.show ; } } Of course, if you do this, all the remote method calls from a client, including those associated with the naming service and distributed garbage collection, go through the web server as well. This means that in order to use this socket factory, you need one machine running the web server, the naming service, and all of your servers. This is useful for functionality testing, but can skew results if you attempt to scale-test.

22.7 Drawbacks of HTTP Tunneling

HTTP tunneling is often considered a bad idea. There are five major reasons for this: Security At its heart, HTTP tunneling involves deliberately circumventing a security mechanism that someone else thought was necessary and worked hard to install. It involves deliberately relaxing the security provisions on a trusted network. Ordinarily, this isnt such a big deal. Youre a reasonable person and remote method calls arent so big a risk especially if you use a secure web server to handle the HTTP traffic. However, and this cannot be stressed enough, you should not enable dynamic classloading if your application will use HTTP tunneling. Downloading classes from outside a firewall and executing them inside a firewall constitutes gross negligence. Id fire anyone who did it. Bandwidth inefficiency RMI is already a verbose protocol; it encodes a lot of information in each message request. Taking an RMI message and wrapping it in an HTTP post by inputting the RMI message as the body of the post and then setting five or six message headers just adds insult to injury. Using HTTP tunneling could easily double bandwidth requirements for many remote interfaces. In particular, consider the output of LoggingServletForwardCommand , which simply prints out the HTTP headers from a request. Connection inefficiency HTTP tunneling does not support keeping connections open and reusing them. Unlike JRMP, in which sockets may be reused for dozens of method calls, HTTP tunneling establishes a new socket connection for each request. While each socket connection is not necessarily expensive, the overhead can add up. Application fragility HTTP tunneling introduces another way that your distributed application can fail. It makes your entire application vulnerable to changes in firewall configuration or network topology. Even worse, when the application fails, you wont immediately think, The firewall changed. Instead, youll spend a day or two wondering just what happened, checking the server configuration, and trying to replicate the problem from other clients. Only after youve exhausted those possibilities will it occur to you that maybe it isnt your application. Loss of protocol-specific features HTTP tunneling uses HTTP and plain-text sockets. You cant change your application to use compressing sockets or RMIIIOP see Chapt er 23 for details on RMIIIOP. In addition, security is nonexistent™Suns implementation of HTTP tunneling doesnt attempt to protect the data at all. This last point is easily overcome. You can sign a license, get the source code to RMI, and then use Suns implementation of HTTP tunneling as a starting point for a secure implementation or an implementation that uses RMIIIOP. The first four points, however, are costs built into HTTP tunneling. Tunneling Through Two Firewalls Many, perhaps even most, corporate networks actually use two firewalls, dividing the world into three zones: The Internet This is not under corporate control at all and is viewed as being highly insecure. The DMZ This is behind the first firewall and in front of the second firewall. Proxy servers that interface to the outside world such as HTTP and mail servers are here. Contractors and software that is not fully under corporate control have frequent access to this part o f the network. The trusted network This is the area behind the second firewall. Sensitive data, corporate applications, and most internal uses are inside the trusted network. If youre developing for this type of network, you may have to tunnel through both firewalls. In order to do this, you will need to customize ServletForwardCommand for the outer web server it should attempt to tunnel through the inner firewall instead of attempt to send a message to an RMI server. That said, HTTP tunneling is also universally used. At the OReilly P2P Conference in February of 2001, I spent a good part of the first day asking attendees how they dealt with firewalls. I asked 13 people and received the following responses: 2 people said, Firewalls are a problem. 11 people said, Oh. We just tunnel through them. I stopped asking when it sunk in that Id just been told that 11 distinct protocols, for everything from distributed computation to performing a naming-service lookup, were all tunneling through HTTP.

22.8 Disabling HTTP Tunneling