Note: This is a new version of this article, updated with the information on a vulnerability in OpenSSL 3.0, which is another example of why you need to keep your software up-to-date and protected.
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.
Table of Contents
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.
TLS vulnerabilities
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.
Critical vulnerabilities in OpenSSL 3.0
The OpenSSL Project released a Security Advisory on November 1, 2022, concerning two critical vulnerabilities discovered in the OpenSSL library versions 3.0.0 to 3.0.6. Both were assigned a High severity level. Both can be triggered during a client or server's validation of an X.509 certificate.
With the first one, X.509 Email Address 4-byte Buffer Overflow (CVE-2022-3602), a specifically crafted email address can overflow four attacker-controlled bytes on the stack. In the case of the second vulnerability, X.509 Email Address Variable Length Buffer Overflow (CVE-2022-3786), a buffer overflow can be caused by a malicious email address abusing an arbitrary number of bytes containing the “.” character (decimal 46) on the stack. The CVEs exploitation may lead to denial of service (DoS) or remote code execution (RCE).
Both CVEs can be triggered if a vulnerable TLS client connects to a malicious server or a vulnerable TLS server requests client authentication and a malicious client connects.
The CVEs were patched in version 3.0.7. If you are using OpenSSL 3.0, you should upgrade to the newest library version as soon as possible: this is the only way to deal with CVE-2022-3602. In the case of CVE-2022-3786, you can temporarily disable the verification of client certificates.
Library versions 1.1.1 and 1.0.2 are not affected by the issue. If the library is bundled with the third-party software you are using, you should update the software as soon as the patch becomes available. This is also the case with operating systems with OpenSSL installed (Ubuntu 22.04, CentOS Stream 9, Alpine Edge, etc.). If you are using BellSoft’s containers based on Liberica JDK and these distributions, you don’t have to worry because our containers do not include this library by default. Also, Amazon Linux 1 and Amazon Linux 2 don’t ship with OpenSSL 3.0, so no patch is required. As far as Alpine Linux is concerned, the patch is already available. The OpenSSL package for Alpaquita Linux has also been updated, the patched version can be found in Alpaquita’s repositories.
OpenJDK distributions, including Liberica JDK, use their own implementation of TLS and therefore are not affected.
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.disabledAlgorithmsproperty of thejava.securityconfiguration 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 -tls1andopenssl s_client -connect localhost:443 -tls1_1should be rejected.openssl s_client -connect localhost:443 -tls1_2andopenssl 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!
