The deadline for retiring early TLS has passed. But, is it really gone?

By July 11, 2018 April 30th, 2019 Blog, Legacy, Patching

In a summer of big security compliance deadlines, one slipped by virtually unnoticed.  While the world was fixated on meeting the strict requirements of GDPR by 25 May, there was little fanfare over 30 June – the day SSL and early TLS was officially retired after a two-year delay.

The Payment Card Industry Security Standards Council first announced the move away from SSL and early TLS versions in 2015 with an effective date in 2016. SSL was deemed obsolete and early TLS (defined as 1.0 and 1.1) was vulnerable to attack, especially “Man in the Middle” exploits like “Heartbleed.”

TLS, SSLCompliance often required replacing hardware and upgrading software. Delays in both prompted the PCI Council to push the retirement date until 2018. With the compliance date now in the past, are there still vulnerable systems in the wild?  And, can anything be done to help bring them into compliance short of costly rewrite or replace efforts?

Undoubtedly the answer to the first question is a qualified “yes.” Older servers and enterprise applications may not be able to upgrade to new encryption standards without being replaced or rewritten.

However, even large, well-established, and successful organizations have difficulty addressing legacy software with the result being an untold number of older applications running in organizations around the world. Rewriting an app or migrating to a newer platform is not possible in many cases, and it’s certainly not scalable in enterprise environments where thousands of applications are deployed on all possible versions of Java and .NET platforms

The answer to the question about achieving compliance without replacing servers and rewriting vulnerable applications is a more definitive “yes.”

Using a virtual container in an application’s runtime allows legacy applications to utilize the latest and most stable TLS protocols and cipher suites without the need to rewrite source code or migrate to a newer Java platform. Out-of-support Java versions (such as Java 5, 6, 7 and soon 8) run as guest JREs on a current version host JVM. The application no longer uses its own out-of-date TLS protocols, but rather offloads this functionality to the most current and patched host JVM.

This configuration offers several unique benefits:

  • Applications that need the latest cryptographic and encryption protocols and cipher suites do not need to be rewritten, redesigned or recompiled
  • Legacy applications that have been developed to specifically utilize an older, broken SSL or TLS version can be automatically upgraded to use the latest TLS version
  • Enterprises do not need to change the Java version of their application nor migrate to another JVM platform
  • Applications are automatically protected against common cryptographic vulnerabilities

Most importantly, organizations become instantly compliant with the latest PCI standards and improve the protection of their customer’s valuable data.



Author Waratek

Some of the world’s leading companies use Waratek to patch, secure and upgrade their mission critical web applications using our next generation technology. Waratek makes it easy for security teams to instantly patch known Java and .NET flaws with no downtime, protect their applications from known and Zero Day attacks, and virtually upgrade out-of-support Java applications – all without time consuming and expensive source code changes or unacceptable performance overhead.

More posts by Waratek