Is SSLContext.createSSLEngine() thread safe? - ssl

Question

I'm using the default JSSE provider in Java 6 (SunJSSE) like so,
SSLContext sslCtx = SSLContext.getInstance("TLS");
Can I call the method sslCtx.createSSLEngine() safely from multiple threads?
Update 1:
The code that's calling createSSLEngine() in this manner is run on the server-side only. Basically, a thread calls this method for every client that connects to the server.

Answer 1

The call to SSLContext.createSSLEngine() seems to be thread-safe. At least based on the fact that the application has not failed with any race-condition-related error.
In trying to find a definitive answer, I downloaded the source code of OpenJDK6 b27 and took a look at it. I’m assuming, of course, that this is the same code that is inside Oracle’s JRE 6.
When SSLContext.createSSLEngine() is called, it in its turn calls the abstract method engineCreateSSLEngine() on whatever implementation it has of the javax.net.ssl.SSLContextSpi class. In this case the implementation is sun.security.ssl.SSLContextImpl. The implementation of the engineCreateSSLEngine() method provided by SSLContextImpl simply returns a new instance of sun.security.ssl.SSLEngineImpl by calling the SSLEngineImpl(SSLContextImpl ctx) constructor.
Inspecting the code, I couldn’t find anything that suggested a possible thread-unsafe operation.

Answer 2

I can also agree with Elliot concerning the thread-safeness of SSLContext.createSSLEngine() in OpenJDK8 (based on analysing the code and performing simple tests).
I added this answer, because there exist situations when you HAVE to re-use SSLContexts (if you do not like wrapper classes or cannot use synchronisation): When connecting to a Wildfly application server EJB using SSL encryption, the jboss-remoting EndpointImpl decides to open a new connection based on a ConnectionKey that contains the SSLContext instance. So if you always specify a new SSLContext for each EJB call, always a new connection is used. The sad thing is, that the connection is considered "shared", so it is not closed after the call (but never re-used, due to the differing ConnectionKeys). After some time, you will only get many of those:
Caused by: java.net.SocketException: No buffer space available
at sun.nio.ch.Net.socket0(Native Method) ~[?:1.8.0_91]
at sun.nio.ch.Net.socket(Net.java:411) ~[?:1.8.0_91]
at sun.nio.ch.Net.socket(Net.java:404) ~[?:1.8.0_91]
at sun.nio.ch.SocketChannelImpl.<init>(SocketChannelImpl.java:105) ~[?:1.8.0_91]
at sun.nio.ch.SelectorProviderImpl.openSocketChannel(SelectorProviderImpl.java:60) ~[?:1.8.0_91]
at java.nio.channels.SocketChannel.open(SocketChannel.java:145) ~[?:1.8.0_91]
at org.xnio.nio.WorkerThread.openTcpStreamConnection(WorkerThread.java:250) ~[xnio-nio-3.6.2.Final.jar:3.6.2.Final]
at org.xnio.XnioIoThread.internalOpenTcpStreamConnection(XnioIoThread.java:247) ~[xnio-api-3.6.2.Final.jar:3.6.2.Final]
at org.xnio.XnioIoThread.openStreamConnection(XnioIoThread.java:226) ~[xnio-api-3.6.2.Final.jar:3.6.2.Final]
at org.xnio.XnioWorker.openStreamConnection(XnioWorker.java:398) ~[xnio-api-3.6.2.Final.jar:3.6.2.Final]
at org.jboss.remoting3.remote.RemoteConnectionProvider.createSslConnection(RemoteConnectionProvider.java:246) ~[jboss-remoting-5.0.0.
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider.createSslConnection(HttpUpgradeConnectionProvider.java:136) ~[jboss-remot
at org.jboss.remoting3.remote.RemoteConnectionProvider.connect(RemoteConnectionProvider.java:206) ~[jboss-remoting-5.0.0.Final.jar:5.
at org.jboss.remoting3.EndpointImpl.lambda$connect$6(EndpointImpl.java:618) ~[jboss-remoting-5.0.0.Final.jar:5.0.0.Final]
at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_91]
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:617) ~[jboss-remoting-5.0.0.Final.jar:5.0.0.Final]
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:536) ~[jboss-remoting-5.0.0.Final.jar:5.0.0.Final]
at org.jboss.remoting3.ConnectionInfo$None.getConnection(ConnectionInfo.java:83) ~[jboss-remoting-5.0.0.Final.jar:5.0.0.Final]
at org.jboss.remoting3.ConnectionInfo.getConnection(ConnectionInfo.java:56) ~[jboss-remoting-5.0.0.Final.jar:5.0.0.Final]
at org.jboss.remoting3.EndpointImpl.doGetConnection(EndpointImpl.java:487) ~[jboss-remoting-5.0.0.Final.jar:5.0.0.Final]
at org.jboss.remoting3.EndpointImpl.getConnectedIdentity(EndpointImpl.java:433) ~[jboss-remoting-5.0.0.Final.jar:5.0.0.Final]
at org.jboss.remoting3.UncloseableEndpoint.getConnectedIdentity(UncloseableEndpoint.java:51) ~[jboss-remoting-5.0.0.Final.jar:5.0.0.F
at org.jboss.remoting3.Endpoint.getConnectedIdentity(Endpoint.java:122) ~[jboss-remoting-5.0.0.Final.jar:5.0.0.Final]
at org.jboss.ejb.protocol.remote.RemoteEJBReceiver.lambda$getConnection$2(RemoteEJBReceiver.java:185) ~[jboss-ejb-client-4.0.9.Final.
at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_91]
at org.jboss.ejb.protocol.remote.RemoteEJBReceiver.getConnection(RemoteEJBReceiver.java:185) ~[jboss-ejb-client-4.0.9.Final.jar:4.0.9
at org.jboss.ejb.protocol.remote.RemoteEJBReceiver.processInvocation(RemoteEJBReceiver.java:128) ~[jboss-ejb-client-4.0.9.Final.jar:4
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:454) ~[jboss-ejb-client-4.0.9.Final.ja
Re-using a static SSLContext fixes this.