Improved Performance of TLS 1.3 in Java JDK 8

Bruno Borges

Transport Layer Security (TLS) 1.3 is the latest version of the TLS protocol, built on the foundation of its predecessors, with significant improvements in terms of security, performance, and simplicity. TLS 1.3 is widely considered one of the most secure network protocols currently available.

Support for TLS 1.3 across Microsoft Azure has started to roll out over the past year, and many services have either added support or now made TLS 1.3 the default.

• General availability: TLS 1.3 with Application Gateway
• Announcing the availability of TLS 1.3 in Azure API Management in Preview
• Prepare for upcoming TLS 1.3 support for Azure Storage
• The All-Inclusive Update for Everything TLS on App Service

Java and TLS 1.3

Significant work was done by Oracle to implement TLS 1.3 in JDK 11 through JEP 332, then backported to JDK 8 8u272 (see JDK-8245466).

In addition to Azure services, the Azure SDK for Java also maintains support and compatibility with Java 8, allowing customers to bring their Java 8 applications to Azure as well as integrating their apps with Azure services seamlessly and idiomatically.

The Bug

With the increasing adoption of TLS 1.3 across Azure, the Azure SDK engineering team noticed certain performance issues involving Java 8 applications. When compared against the same scenario but running with JDK 11, the issue no longer appeared and the expected throughput was achieved.

Upon further analysis, it was discovered that the issue was caused by a bug that once affected JDK 11 initial implementation of TLS 1.3, which was fixed in JDK 20 and backported by Oracle: JDK-8293562 KeepAliveCache Blocks Threads while Closing Connections into JDK 11 as well as JDK 17. Given the importance of supporting customers still deploying Java 8 applications, it became clear we had to backport that fix also to JDK 8.

Performance Gains After the Fix

After fixing the issue in an internal build of JDK 8, we noticed significant performance gains (or the recovery of expected performance!), the Azure SDK team confirmed the fix worked, and what once was a 500 rps (requests per second) Java 8 based workload over TLS 1.3 protocol, became a 15,000 rps leading to 30 times better performance.

The next step was to rollout that fix into JDK 8.

The Backport(s)

Not all backports are straightforward or as simple as “just apply this patch to this other branch“. Often, especially within the JDK project and specifically the JDK 8 project, a backport demands substantial effort. This case was no exception.

The Java Engineering Group at Microsoft, and in particular our engineer Dhamoder Nalla, started digging into the issue, and identified a series of other patches that also had to be backported besides the original issue:

• Dubious collection management in sun.net.www.http.KeepAliveCache
• Make HttpURLConnection default keep alive timeout configurable 
• HttpClient default keep alive timeout not followed if server sends invalid value 
• Create Test Cases to cover scenarios for JDK-8278067
• Keep-Alive timeout of 0 should close connection immediately 

With all these issues fixed and backported, and if you are looking into TLS 1.3 for Java 8 applications, stay tuned for the upcoming July updates of JDK 8 from Eclipse Temurin and other JDK distributions, as they will contain these critical patches.

Happy Java coding!

Bruno Borges Principal PM Manager, Java Engineering Group

Follow