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.
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 SSLrsh.java
to run remote commands.
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
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 SSLSocket.java 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.
extends SSLSocket to provide a java implementation of
Its unit test is a simple implementation of
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 $