TLSv1 and TLSv1.1 Disabled by Default in Java
By Pete Freitag
The OpenJDK Crypto Roadmap states that TLSv1 and TLSv1.1 will be disabled by default in OpenJDK versions released after April 20, 2021. This change also applies to Oracle, and all the JVMs that are derived from OpenJDK.
What versions of Java are impacted?
Java LTS versions 11.0.11, 1.8.0_291 and up have TLSv1 and TLSv1.1 disabled by default.
How are they disabling it? or how can I reenable it if I need to?
One nice feature you may not realize exists is the java.security
file. In Java 11 and up it is located in the folder conf/security/
under your JAVA_HOME
. This file has a property called jdk.tls.disabledAlgorithms
, right now it looks like this:
jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \ EC keySize < 224, 3DES_EDE_CBC, anon, NULL
You can see that this setting is currently used to disable SSLv3
and a few other ciphers / parameters.
After April 20, 2021 my guess is that they are going to add TLSv1
and TLSv1.1
to this list.
Update: My guess was correct, this is what they did.
This is good to know, because you can make the change now to test and see if your application is impacted by adding those algorithms to jdk.tls.disabledAlgorithms
now.
How can I re-enable TLSv1 and TLSv1.1 on newer JVMs?
If it turns out that you do need to still connect to https servers over these weaker protocols, then you can move them out of jdk.tls.disabledAlgorithms
and into the setting jdk.tls.legacyAlgorithms
.
According to the docs:
In some environments, a certain algorithm may be undesirable but it cannot be disabled because of its use in legacy applications. Legacy algorithms may still be supported, but applications should not use them as the security strength of legacy algorithms are usually not strong enough in practice.
During SSL/TLS security parameters negotiation, legacy algorithms will not be negotiated unless there are no other candidates.
This should only be done however if you are not able to upgrade the legacy servers to TLSv1.2
or TLSv1.3
, for example because you don't operate them.
What error message might I get due to this?
Here's one you might see:
Unknown host: The server selected protocol version TLS10 is not accepted by client preferences [TLS13, TLS12]
Or:
The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: "The server selected protocol version TLS10 is not accepted by client preferences [TLS12]".
You might also get a SSL Handshake Exception javax.net.ssl.SSLHandshakeException
.
Update: So far I've seen this issue come up a few times in JDBC / database connections using TLS / SSL, and https (eg cfhttp) connections. One thing to note is that some versions of MySQL Community edition only support TLSv1, you would need the paid version of MySQL to get TLSv1.2 support.
I've also seen this show up in MSSQL / SQL Server TLS connections to older servers. For the data direct JDBC drivers (used by ColdFusion) you may need to add CryptoProtocolVersion=TLSv1.2
to the connection string.
TLSv1 and TLSv1.1 Disabled by Default in Java was first published on April 15, 2021.
If you like reading about java, tls, openjdk, or versions then you might also like:
- Java versions supporting TLS 1.3
- Java LTS Versions Explained with EOL Dates
- Travis CI Error when installing oraclejdk8
- How to Resolve Java HTTPS Exceptions
Weekly Security Advisories Email
Advisory Week is a new weekly email containing security advisories published by major software vendors (Adobe, Apple, Microsoft, etc).
Comments
For more on the JVM updates (especially from the perspective of CF users), see a post I did:
https://www.carehart.org/blog/client/index.cfm/2021/4/26/new_java_updates_for_Java_8_and_11_as_of_Apr_2021
(It's my experience with news like this that some readers could miss such a point and be fearing that this change might "just happen" to them, even without updating the JVM version.)
So to be clear: folks using Java 11.0.10 or Java 1.8.0_281 or earlier (the current Java "long term support releases") are unaffected, until those are updated and one implements that update.
But great point about how to go about "trying" the change before a subsequent update forces the change.