End of life for old TLS in OpenJDK and Liberica JDK
Published June 3, 2021
TLS 1.0 and 1.1 used to be a safety standard for a long time, but not anymore. The time to upgrade your security protocols is now long overdue. Let’s discuss the risks and benefits of switching to the modern version of TLS and if it is actually worth it.
Deprecation of TLS 1.0 and 1.1
The first steps to leaving the outdated TLS behind were taken quite some time ago. IETF deprecated old version usage in March of 2019. All popular browsers dropped the support for 1.0 and 1.1 in 2020, with only 1% of popular websites still working with these weaker protocols.
As we already discussed, Liberica JDK release cycle is managed to ensure top-notch security, so in our April build, we disabled TLS 1.0 and 1.1 by default. This was executed by adding
SSLv3, TLSv1, TLSv1.1 into the
jdk.tls.disabledAlgorithms property of the
java.security configuration file.
jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
BellSoft experts recommend keeping your online apps up-to-date to protect your clients and your business from attacks. Click the button below to allow our engineers to take care of your security.
These are just some of the exploits1 proven to work with older versions of TLS.
- POODLE (“Padding Oracle On Downgraded Legacy Encryption”) originally took advantage only of the SSL 3.0 protocol, but in December of 2014, there was announced a new variant of the attack, exploiting flaws of CBC encryption mode in TLS up to 1.2. The “Man In The Middle” would force the client to employ the older SSL 3.0 protocol to communicate with the server and, as such, rely on the outdated cryptographic method — cipher block-chaining (CBC). At the time of writing, in May 2021, about 4% of 150.000 most popular sites still supported SSL 3.0 or lower and were vulnerable to attack2. And we can assume that this percentage is bound to increase if we take into account less popular (and likely less protected) servers.
- FREAK (“Factoring RSA Export Keys”) is another type of MITM (“Man In The Middle”) attack tricking the client and server into using outdated cipher suites that can be cracked in just a few hours with modern computing power. The attacker modifies the request from the client to enforce using the 40 or 56-bit encryption that used to be safe in the 90s but not anymore.
- BEAST (Browser Exploit Against SSL/TLS) was discovered as early as 2002, but the proof of concept was demonstrated only in 2011. This attack relies on injecting a Java applet into the victim’s machine and then sending crafted data to the target website over SSL. The attacker then sniffs the traffic to find the encrypted crafted data created by the applet and thus discovers the plaintext block.
- CRIME (Compression Ratio Info-leak Made Easy) exploits the compression algorithm in TLS utilized to reduce bandwidth. As repeated byte sequences are replaced by pointers to the first instance of the sequence, an attacker can inject different characters into the victim’s cookie and monitor the size of the response. This makes it possible to reconstruct the cookie value.
- Heartbleed is a vulnerability that exploits the heartbeat extension of OpenSSL. In TLS up to version 1.2, Heartbeat is a method to keep a connection alive by sending a message to the server to request a response containing the client’s data and its size. The trick is that an attacker can modify the size of the requested response, and the server will reply with large chunks of random data from its memory — including, for example, the private key of the server.
Were there any real successful attacks?
Sure there were. A list of organizations falling victim to these exploits includes Canadian tax agency3, UK parenting site4, the large USA hospital chain5 and even Yahoo mail6 — and these are just some cases that were actually discovered. Nobody really knows how many successful attacks went unnoticed.
While there are no public cases of Java™-affected attacks, big companies take these risks very seriously. For example, in 2011, Mozilla was about to ban Java™ from Firefox right after the BEAST vulnerability was demonstrated, although Oracle resolved the issue with a promptly released patch7. The risk of new exploits suddenly popping up is always present within the systems that are not up-to-date.
What’s going to happen to my Java apps?
Probably nothing, if you update regularly. It is likely you are already using the TLS 1.2 protocol. And even if you keep older TLS on client and server applets in your LAN or intranet, they will still be able to handshake and exchange information.
But maybe you work with people that have never updated their web browser for the last ten years. Or you like to keep your client apps up-to-date but still rely on the good-old server program written in 1999. And we get it — “If it ain’t broke, don’t fix it.”
However, this time the ancient code may stop working.
What can I do?
There are a few ways to solve the potential problems.
- You may update and then enable back the TLS 1.0 and 1.1 support in your runtime configuration by removing them from the**
jdk.tls.disabledAlgorithms** property of the**
java.security** configuration file. Be aware, that also means you accept the risk of dealing with security vulnerabilities of older TLS protocols described earlier, so think hard if it is worth it. You will just postpone the issue you will need to deal with in the future.
- If you are absolutely not going to update, you can still manually disable TLS 1.0 and 1.1 on your server. In your configuration files, find the lines referring to protocols (for example,
server.ssl.enabled-protocols=TLSv1.1, TLSv1.2in Apache Tomcat) and modify them to keep only the safe versions of TLS. Don’t forget to test your server with the OpenSSL toolkit. Run the following commands:
openssl s_client -connect localhost:443 -tls1and
openssl s_client -connect localhost:443 -tls1_1should be rejected.
openssl s_client -connect localhost:443 -tls1_2and
openssl s_client -connect localhost:443 -tls1_3should be accepted and print the certificate’s details.
- The safest solution is to update all your apps on the server and the client sides to be compatible with newer TLS. After all, we upgrade security for a reason. This will take more time and effort, but it’s a comprehensive solution in the long run.
Bye, old TLS
So, should you work in legacy mode, or is it time to rebuild your apps following modern safety standards? The choice is yours, but the April update of OpenJDK and Liberica JDK marks one more step to deprecating the older TLS security protocol. Get the latest and safest version of Liberica JDK!