SSLSocket: SSLeay for java

Other wrappers exist to provide SSL sockets for java, usually by providing a replacement SocketImpl and SocketImplFactory.

We are trying to avoid that if possible.

Update: 2001

I actually stopped work on this quite a while ago, when it proved impossible to get the socket out of the existing SocketImpl - without getting nasty problems in the native methods. This was all to work around the silly separation of Socket and ServerSocket.

Since then, I've successfully used Sun's JSSE for testing.

A year or so ago, when the JSSE spec's came out, I wrote as a client for SSLrshd. However, JSSE and the other Java SSL implementations I've looked at did not support the reversed SSL client model used by SSLrshd. I've recently added an option to SSLrsh to support the conventional SSL client roles, and have been able to use to run remote commands.


Our SSLSocket class simply extends Socket - so that we immediately gain any benefits from updates to that class, and simply provides the functions necessary to start SSL and return SSL input and output streams.

The goal, apart from avoiding the replication of any of the standard code, is that an SSLSocket can be used as an ordinary Socket and only becomes magic once SSL has been turned on via SSLconnect() or SSLaccept(). This allows us considerable flexibility.


We avoided all the hassle of trying to do an SSLServerSocket class (without having to replicate all of PlainSocketImpl) by simply allowing an SSLSocket to be initialized from a Socket which is the return from ServerSocket.accept().

This is a JNI native library which interfaces to Eric Young's SSLeay libraries using some of the code from libsslfd - though greatly simplified at this point.

For maximum portability, we provide the thread locking needed by SSLeay using the JNI's Monitor methods rather than using native mutex's directly.


SSLrcmd extends SSLSocket to provide a java implementation of ssl_rcmd(3). Its unit test is a simple implementation of SSLrsh.

The proxy support in ssl_rcmd(3) is not implemented (yet).


A simple unit test, is able to gather the home page from either a HTTP or HTTPS web server, so we know the concept works as expected. There is still a fair bit of work to do though to allow java callbacks from the native code to deal with cert verification failures, prompting for PEM passwords etc.

Bottom line - don't hold your breath :-)

$Id: SSLSocket.html,v 1.3 1998/07/30 13:31:04 sjg Exp $
Copyright © 1997-2001 Crufty.NET