We will first explain how to get the demo working and then move on
to some explanation, usage recommendations, and JDK version notes.
It is recommended that you read this entire document even if some
sections may not seem to apply to you at the moment.
There are no special requirements RMI has about the socket layer that
transports its calls. In other words, the core SSL library does not know
or care about RMI, it is an add-on on top of it. All we do is provide
a description and a demo of how we think our library should be used
to secure RMI.
If you want to do
something differently, just do it.
There are three players in RMI: the server, who offers
services to remote programs; the client, who uses those services; and
the registry, which helps clients find servers.
These player communicate using sockets and all this communication can
be secured using SSL/TLS. This is what is done in the demo,
where all communication between any of these players is encrypted using
strong cryptography and clients and servers are authenticated using certificates.
To run the demo follow these steps:
As mentioned before, the entire communication was secured via SSL/TLS.
See below for more information.
Actually using RMI over SSL is extremely simple. Done in the way
explained in this document the only changes required are in the
setup code, and possibly in the use of a different RMI registry.
In short, all that is required is that at the beginning of each
application that starts RMI clients, servers, or a registry
the SSL policies are set via SSLContexts and a custom socket
factory is activated. That's all. As implemented in the demo
this requires just three additional methods which could be
used in almost exactly the same way in real world applications,
only the certificates and private keys used should be
The assumptions the statements above are based on are:
For more information about the setup required please see the demo
source code, especially the class SSLRMIUtil .
RMI uses sockets for all network communication. As such it is well suited
to be secured using SSL. Because the designers had that in mind and do not
instantiate sockets directly and use a SocketFactory instead this is also
fairly easy to do. Before we get into that, let us first explain how
RMI uses sockets.
This section describes who uses what type of sockets for what purpose.
It assumes that no code downloading occurs, see also the note below.
As can be seen from the explanation above, there are two types of
In principle both are worth protecting, the second obviously more than
the first, after all this is what we are here to do. The communication
with the RMI registry is not as critical as might appear at first.
Assume an attacker posing as the RMI registry to redirect calls
to its own server. If the RMI registry traffic is not secured it
can of course easily do so, but the client would detect the
tampering in the server authentication phase of the actual RMI call
as that call is secured.
That means, all that can really be achieved is a denial of service
attack that prevents the client from making some or any RMI calls,
but the same effect can be achieved by preventing the client from
connecting to the registry in the first place. The difference is
only when that tampering is detected.
In environments where this is not a concern it is possible to leave
RMI registry traffic unprotected. Although there is no immediate way
in the RMI API for a SocketFactory to distinguish between sockets
created for the RMI registry and sockets created for ordinary RMI
calls this can be done by simply checking the port number, assuming
the default port 1099 or another port number known in
advance is used for the RMI registry. This is demonstrated
in the SocketFactory implementation supplied with the demo, see its
In case you decide to leave RMI registry traffic unsecured there
is actually no longer a need to use the customized registry
supplied with the demo. Although the registry's call to the
server in reponse to its registration request will fail
(talking plain instead of SSL/TLS) the
registration is successful nevertheless. In other words, you
can use the standard RMI registry or whatever other registry
you want to use, which also allows you to use a common registry
for secured and not secured RMI calls. However, remember that
using a secured RMI registry provides some additional security.
As shown, all of the three partners involved in RMI all
except the client, which uses client sockets only, use both
client and server sockets. That means, assuming strong client
and server authentication is always used, they all require the
respective certificates. This is reflected in the setup code the
In the demo implementation this setup is achieved
using a single call to SSLRMIRegistry.setSSLSocketFactory()
which performs three things:
Again, note that strictly speaking the SSL RMI registry does
not need a client certificate, as noted before. Also note
that if you decide to leave RMI traffic unprotected, the
server certificates for the RMI registry and the client certificate
for the RMI server are not required either. In other words,
in that case you only need client certificates on clients
and server certificates on servers.
Some improvements have been made to RMI 1.2. In particular,
it is possible to use different SocketFactories
for different remote objects. This also makes it possible to use
secured and non-secured calls within a single VM.
However, the current
demo does not make use of these improvements. As mentioned
before this does preclude you from using them in your own