Recently we encountered an exception, The server selected protocol version TLS10 is not accepted by client preferences [TLS13, TLS12], when connecting to one of our existing server applications. We were perplexed by the error because the connection was working till previous day. There was no change in the client and server applications.

How TLS protocol version negotiation works between client and server

There exists various TLS versions and some of them are not supported by applications due to various security reasons. TLS protocol has a built in mechanism to negotiate the specific protocol to use. When a client connects to the server, it informs the server the highest version of TLS it could use in the connection and the server decides the version that should be used in the connection. If the version chosen by the server is not supported or accepted by the client, the client stops the negotiation and closes the connection.

What was the cause of the exception?

After a small research we identified that the OpenJDK version in the client side was upgraded by the software patch management team. When we checked the changes in the latest installation, it was identified that the tls versions TLSv1 and TLSv1.1 are disabled in java security configuration file. In Java 11 and up the security configuratio file is located in the conf/security/ folder under JAVA_HOME. This file contains a configuration property called jdk.tls.disabledAlgorithms which contains the names of all disabled transport layer security algorithms.

The exception that we got is because the client application, after the openjdk upgrade, supports the latest versions (TLS 1.2 and above) of TLS protocol but the server would like to use the version TLSv1.0 during the connection.

Affected OpenJDK versions:

Version Release number OpenJDK 8 8u292 and newer OpenJDK 11 11.0.11 and newer OpenJDK 16 and above All versions

Why to disable TLSv1 and TLSv1.1 algorithms?

For the past few years, the industry experts have been recommending to stop using all SSL versions and the vulnerable versions of TLS protocol. TLS 1.0 is vulnerable to man-in-the-middle attacks, risking the integrity and authentication of data sent between the server and client.The Browser Exploit Against SSL/TLS (BEAST) attack allows an attacker to decrypt data exchanged between two parties by taking advantage of a vulnerability in the implementation of the Cipher Block Chaining (CBC) mode in TLS 1.0.

Some of the implementaion of versions 1.0 and 1.1 are also vulnerable to POODLE (Padding Oracle on Downgraded Legacy Encryption) attack because they accept an incorrect padding structure after decryption.

How could it be re-enabled in OpenJdk?

The affected applications could re-enable these versions of TLS because they are not completely removed from OpenJDK implementaion. You could follow the below steps to re-enable TLSv1.0 and TLSv1.1 versions at your own risk.

1. Ensure the security.overridePropertiesFile value in the java.security file is set to true.
2. Create a file named enableLegacyTLS.security.
3. Copy the propery jdk.tls.disabledAlgorithms and its value from the java.security file and add it to the file enableLegacyTLS.security.
4. Remove TLSv1 and/or TLSv1.1 from the copied list.
5. Start the application with -Djava.security.properties = path/to/enableLegacyTLS.security.

You could also simply remove the values TLSv1, TLSv1.1 from the list of values against the property jdk.tls.disabledAlgorithms present in the java.security file. This could permanently enable the vulnerable TLS versions but this is more riskier than the approach using enableLegacyTLS.security file.

Conclusion

The TLS protocol versions 1.0 and 1.1 are no longer considered secure and have been superseded by more secure and modern versions.This article is written to expalin the java users on a workaround solution for the problem, related to these versions of TLS protocol, which might come after upgrading to a java version in which the TLSv1.0 and TLSv1.1 versions is disabled by default.