SSLContext initialization
java, jsse, security, ssl
Solution
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):
- All support all protocols.
- All protocols are enabled on the server side by default.
- the client-side protocols enabled by default vary:
- `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.
- If FIPS is enabled, SSL is not supported (so not enabled 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.
Problem
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