Over a million developers have joined DZone.

Deadline to Retire SSL and Early TLS: What Does This Mean?

DZone's Guide to

Deadline to Retire SSL and Early TLS: What Does This Mean?

Along with the GDPR deadline in May, the deadline for retiring early TLS and SSL passed almost unnoticed. But, is it really gone?

· Security Zone ·
Free Resource

Discover how to provide active runtime protection for your web applications from known and unknown vulnerabilities including Remote Code Execution Attacks.

In a summer of security compliance deadlines, one deadline slipped by virtually unnoticed.  While the world was fixated on meeting the strict requirements of GDPR by May 25th, there was little fanfare over June 30th — the day SSL and early TLS were 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. Now, with the compliance date in the past, are there still vulnerable systems in the wild?  And, can anything be done to help bring them into compliance and short of costly rewrite or replacement efforts?

Undoubtedly, the answer to the first question is a qualified “yes.” Older servers and enterprise applications may not be able to upgrade to the 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 versions 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.

Find out how Waratek’s award-winning application security platform can improve the security of your new and legacy applications and platforms with no false positives, code changes or slowing your application.

security ,tls ,ssl ,gdpr ,deadlines ,legacy applications

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}