Are SSLContext and SSLSocketFactory createSocket thread safe?

Question

In my tests I was able to use both without problems, but I could not find documentation saying wheter SSLSocketFactory.createSocket() is thread safe or not. It is possible to use the same SSLSocketFactory in mutiple threads to create SSL sockets?

My application uses a class that deals with upgrading plain text sockets to SSL:

public class SSLHandler() {
    public Socket upgradeToSSL(Socket plainSocket) {
        SSLSocket sslContext = SSLContext.getInstance("TLS");
        TrustManager[] trustManager = new TrustManager[]{
            new MyOwnTrustManager()
        };

        sslContext.init(null, trustManager, null);
        SSLSocketFactory sslsocketfactory = sslContext.getSocketFactory();

        sslSocket = (SSLSocket) sslsocketfactory.createSocket(
                    remoteSocket,
                    remoteSocket.getInetAddress().getHostAddress(),
                    remoteSocket.getPort(),
                    true);

        return sslSocket;
    }
}

The SSLHandler class is used in mutiple threads like this:

Socket plainSocket = new Socket(host, port);
//Do some stuff in plain text...

//Lets use TLS now
SSLHandler sslHandler = new SSLHandler();
sslHandler.upgradeToSSL(Socket plainSocket);

plainSocket = upgradeToSSL(plainSocket);

So, for each new thread a SSLHandler is created. To avoid this I'm thinking in refactoring the SSLHandler using the Singleton pattern:

public class SingletonSSLHandler() {
    private SSLSocket sslContext;
    private SSLSocketFactory sslSocketFactory;

    //GetInstance() and etc.

    private SingletonSSLHandler() {
        sslContext = SSLContext.getInstance("TLS");
        TrustManager[] trustManager = new TrustManager[]{
            new MyOwnTrustManager()
        };

        sslContext.init(null, trustManager, null);
        sslSocketFactory = sslContext.getSocketFactory();
    }

    public static Socket upgradeToSSL(Socket plainSocket) {

        sslSocket = (SSLSocket) sslsocketfactory.createSocket(
                    remoteSocket,
                    remoteSocket.getInetAddress().getHostAddress(),
                    remoteSocket.getPort(),
                    true);

        return sslSocket;
    }
}

Answer 1

The question can't be answered so easily. The reason is that there is the implementation, but also the contract level.

Implementation

The SSLServerSocketFactory class is abstract and has a plugin extension mechanism. So you can't be sure what implementation you're having from the theoretic standpoint.

The default implementation is just a dummy and gets exchanged by an implementation instance of the provider that is being chosen by the JVM:

//
// The default factory does NOTHING.
//
class DefaultSSLServerSocketFactory extends SSLServerSocketFactory {
...
}

There are some signs of synchronization in the abstract class. To give an answer to the implementation in the JDK, the question would need to be analyzed for every JDK version on each operating system (Windows, Linux, Mac OS).

The existance of cricital sections (synchronized) mean nothing when you come to the contract level in the next section. The contract level is what counts in this discussion from my perspective.

Contract

In fact, if there's no API documentation assuring/promising it's thread-safe. So, in theory it is not. You can't rely on anything that you don't have an API contract for. Please read this reference to Josh Blochs 'golden rule 70: Document thread safety' for a very detailed discussion on assumptions about relying on thread-safety.

I could write a non-thread-safe SSLServerSocketFactory implementation using the extension mechanism mentioned above. The lack of thread-safety wouldn't be a bug because it's not mandatory per interface contract.

Summary

To summarize, the API doesn't assure that all implementations are thread-safe. So there's no way to say that there will be a (future) implementation not thread-safe.