I'm looking at the JSSE
reference guide, I need to obtain an instance of SSLContext
in order to create a SSLEngine
, so I can use it with Netty
to enable security.
To obtain an instance of SSLContext
, I use SSLContext.getInstance()
. I see that the method is overridden multiple times, so I can chose the protocol and security provider to use.
Here, I can see the list of algorithms that can be used. Which algorithm should I use to enable secure communication?
Also, since it is possible to specify the security provider to use, which provider should I use?
Thanks
As you can see in the standard names documentation, all entries (SSLv3, TLSv1.0, TLSv1.1, ...) say that they may support other versions.
In practice, in the Oracle JDK (and OpenJDK), they all do. If you look at the source code, the TLS10Context
class is what's used for TLS, SSL, SSLv3 and TLS10, TLS11Context
is used for TLSv1.1 and TLS12Context
for TLSv1.2. All support all versions of SSL/TLS, it's what's enabled by default that varies.
This may be different with another provider or JRE vendor. You should of course pick one that's at least going to support the protocol version you want to use.
Note that the protocol used is determined later on using SSLSocket.setEnabledProtocols(...)
or its SSLEngine
equivalent.
As a general rule, use the highest version number you can (SSLv3 < TLSv1.0 < TLSv1.1 ...), which may depend on what the parties with which you want to communicate support.
Which protocols are enabled by default varies depending on the exact version of the Oracle JRE.
When looking at the source code for sun.security.ssl.SunJSSE
in OpenJDK 7u40-b43, TLS
is simply an alias for TLSv1
(and so are SSL
and SSLv3
), in terms of SSLContext
protocols. Looking at the various implementations of SSLContextImpl
(which are inner classes of SSLContextImpl
itself):
TLS10Context
(used for protocol SSL
, SSLv3
, TLS
, TLSv1
) enables SSLv3 to TLSv1.0 by default on the client side.TLS11Context
(used for protocol TLSv1.1
) also enables TLSv1.1 by default.TLS12Context
(used for protocol TLSv1.2
) also enables TLSv1.2 by default.This changes in Java 8, in conjunction with the new jdk.tls.client.protocols
system property.
Again, when looking at the source code for sun.security.ssl.SunJSSE
in OpenJDK 8u40-b25, SSLContext
protocols TLSv1
, TLSv1.1
, and TLSv1.2
also make use of TLS10Context
, TLS11Context
and TLS12Context
, which follow the same logic as in Java 7.
However, protocol TLS
is no longer aliased to any of them. Rather, it uses TLSContext
which relies on the values in the jdk.tls.client.protocols
system properties. From the JSSE Reference guide:
To enable specific SunJSSE protocols on the client, specify them in a comma-separated list within quotation marks; all other supported protocols are then disabled on the client. For example, if the value of this property is "TLSv1,TLSv1.1", then the default protocol settings on the client for TLSv1 and TLSv1.1 are enabled on the client, while SSLv3, TLSv1.2, and SSLv2Hello are disabled on the client.
If this property is empty, all protocols are enabled by default on both client and server side.
Of course, in recent versions of Oracle JRE 8, SSL is also completely disabled by default (so removed from those lists).
Note that in both cases (JRE 7 and 8), the SSLContext
you get by default via SSLContext.getDefault()
out of the box is more or less equivalent to an SSLContext
obtained with protocol TLS
and initialised with the default truststore parameters and so on.