This question assumes that the client and server are using the
SslRMIClientSocketFactory and SslRMIServerSocketFactory classes
introduced in Java 5.

Suppose a client application wants to connect to a server through
SSL/RMI and authenticate the server's identity. Presumably, the server
will have exported a remote object, passing instances of
SslRMIClientSocketFactory and SslRMIServerSocketFactory to
UnicastRemoteObject.exportObject(). Meanwhile, the client is set up
with a "truststore" file to only allow SSL connections to the desired
server.

Now, what prevents a man-in-the-middle attack? What if a malicious
server intercepts the initial connection request from the client and
has exported its own remote object, but with a plain (non-SSL)
RMIClientSocketFactory? The client normally uses its truststore to
specify what servers it can connect to through SSL, but the client did
not specify that connections must be through SSL.

Can the client verify that the RMIClientSocketFactory provided is, in
fact, an SslRMIClientSocketFactory?

---

Clarification of Question by motravo-ga on 31 Jan 2006 20:18 PST

Finally found the answer. This issue is not new to Java 5--the same
situation arises when using a custom implementation of
RMIClientSocketFactory, which was how you implemented RMI over SSL
before SslRMIClient(Server)SocketFactory came along.

Here is an enlightening discussion of the problem:
http://archives.java.sun.com/cgi-bin/wa?A2=ind0101&L=java-security&P=R4936&I=-3

Basically, authenticate the registry first by passing an
SslRMIClientSocketFactory to LocateRegistry.getRegistry. Then, you are
simply trusting the registry (whose identity you have confirmed) to
provide the correct remote object reference (with its
RMIClientSocketFactory).