SSL for Transport Security

RMI messages travel over the network in clear and are vulnerable to network-based attacks. As we argued in the RMI Over SSL section of Chapter 6, Securing the Wire, this is usually not a concern because RMI is designed to be used within a trusted environment. In cases where the underlying network cannot be trusted to adequately safeguard the network traffic, SSL can be used to secure the transport. In the simple case of a class implementing a remote reference and extending the class UnicastRemoteObject, this can be accomplished simply by initializing the UnicastRemoteObject with appropriate factories for creating communication sockets. These details and the source code for server and client socket factories to create SSL sockets are covered in Chapter 6. Here we focus on modifying the sample application ex1 so that it uses SSL to protect data exchanged over a network.

To keep our modifications separate, the contents of the subdirectory ch8ex1 are copied to the subdirectory ch8ex3. The first step would be to add source files for factory classes RMISSLServerSocketFactory and RMISSLClientSocketFactory under the directory common. These factory classes have already been covered in Chapter 6, Securing the Wire.

The next step is to change the implementation classes for remote interfaces. For example, the following is a constructor of the class server.RemoteBankImpl:

public RemoteBankImpl(BankIntf bi) throws RemoteException {
  this.bi = bi;
}

becomes:

public RemoteBankImpl(BankIntf bi, int port, RMIClientSocketFactory
    clientFactory, RMIServerSocketFactory serverFactory)
    throws java.rmi.RemoteException {

  // Initialize UnicastRemoteObject with socket factories
  super(port, clientFactory, serverFactory);

  this.bi = bi;
  this.clientFactory = clientFactory;
  this.serverFactory = serverFactory;
  this.port = port;
}

In the modified constructor, we are not only initializing the super class UnicastRemoteObject with a port number and socket factories, but are also storing these within the RemoteBankImpl object. These come in handy when other methods of this class instantiate other remote classes, such as RemoteAccountImpl and RemoteIteratorImpl. It goes without saying that the code within the file serverRemoteBankServer.java that instantiates RemoteBankImpl needs to create instances of socket factories RMISSLClientSocketFactory and RMISSLServerSocketFactory and use the new constructor. Also, the classes RemoteAccountImpl and RemoteIteratorImpl need to be changed to use port and socket factories to initialize the super class UnicastRemoteObject.

Once these modifications are in place, compiling and running the sample application is similar to what we did in the last section. The only thing to keep in mind is that now the server program needs a keystore with a server certificate and the client program needs a keystore for trusted certificates. We can create a keystore with a self-signed certificate that functions both as a keystore with server certificate for the server and as a truststore for the client, at least for experimentation. Also, while running the programs, we need to set the appropriate system properties, as we did for the examples in Chapter 6.

Let us now run the modified sample application. We assume that the working directory is c:ch8ex3 and all the files are already compiled and the jar files have been created. By the way, there is a script file, named comp.bat, that does exactly this.

Let us begin execution of the sample application with creating a keystore file test.ks. The contents of the certificate really don't matter, at least for this experimentation.

C:ch8ex3>keytool -genkey -keystore test.ks -storepass changeit 
-keypass changeit -dname 
"CN=Pankaj Kumar,OU=OVBU,O=HP,L=Santa Clara,ST=CA,C=US"
					

Run the RMI Registry in one command window,

C:ch8ex3>rmiregistry
					

And run the server program in another window.

C:ch8ex3>java –cp server.jar;common.jar 
-Djavax.net.ssl.keyStore=test.ks 
-Djavax.net.ssl.keyStorePassword=changeit server.RemoteBankServer
RemoteBank Server ready.

And finally, run the client program in the third window.

C:ch8ex3>java -cp client.jar;common.jar;server_stub.jar 
-Djavax.net.ssl.trustStore=test.ks client.RMIBCShell localhost
					

You can see that these are the same commands used for running the sample application in the section Sample Application Using RMI, except for SSL-specific system properties.

How is the client able to talk SSL when we haven't touched any code in any of the client source files? The RMI magic is at work. When the server registers the remote object with RMI Registry, the registration information includes the socket factory class names. The client then loads the client socket factory class and uses it to establish the communication channel with the server.

Use of the SSL socket factories protects communication between client and the RMI server program, but what about the communication with the RMI Registry itself? This is still over plain TCP/IP.