Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

A Brief History of TLS

DZone's Guide to

A Brief History of TLS

In this post, we travel back to the dark days before TLS, or even SSL, and show how Transport Layer Security evolved to what it is today.

· 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.

So we've all heard of SSL and TLS, but what are they, and how do you use them securely?

Well, to start with, you don't use Secure Sockets Layer (SSL) securely anymore. But what about TLS? And what versions?

To start to dig into this, we'll begin by looking at what SSL is, where it started, and how it evolved into TLS. Then we'll discuss what exactly TLS is, how it works, how you can configure it, and how you use it with HTTP (creating the ubiquitous HTTPS), and how you can use it without HTTP.

Secure Network Programming started it all, back in 1993. Thomas Woo and his collaborators at the University of Texas at Austin designed a network communications protocol that supported encrypted communications. The interface mirrored the Berkeley Sockets API as much as possible to make the system easy to use. This was desperately needed at the time - until then, all remote connections were via Telnet and were unencrypted. This included administrative connections. All that info flowed across networks unprotected - data, administrative credentials, all of it. It was a good call - it did begin to gain traction, as there was a clear need, and inspired the development of SSL over at Netscape.

SSL v.1.0 was finished in 1994 but never released. It was horribly flawed, and the designers knew it. So they trashed, it, and moved onto version 2.0, which was released in 1995. This version, though not as bad as v.1.0, also had significant issues. Version 3.0, a completely redesigned protocol, was released in 1996 to address these flaws. It remained in common use until 2014, when POODLE was released, which compromised all SSL v.3.0 block ciphers. RC4, SSL v.3.0's only streaming cipher, was also broken. In 2015, SSL v.3.0 was blackballed by the IETF. You can't use it today, but still, a 20-year run isn't bad. And it heavily influenced TLS v.1.0, which was first released in 1999.

TLS v.1.0 was close to SSL v.3.0 but was different enough to warrant a new name and version (plus, SSL was a Netscape thing, and the designers of TLS wanted it to be open). It would still allow users to fall back to SSL v.3.0 (which has been taken advantage of since then to roll encryption back to breakable protocols from relatively unbreakable TLS configurations). Since then, TLS has gone through two more iterations, bringing us to TLS v.1.3. Now, TLS v.1.3 is demonstrably more secure than v.1.2 but is still not the default for most web browsers as v.1.3 isn't as widely supported as it needs to be, and still breaks things like TLS proxies, making it infeasible for larger organizations.

This brings us to where we are today. TLS v.1.3 is as secure of a protocol as we know how to design and has been continuously upgraded to remove breakable algorithms like RC4 or MD5. If you have end-to-end control over your systems TLS v.1.3 is the way to go today. If not, TLS v.1.2 is your friend. SSL, well, best not to be seen with that guy at all.

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.

Topics:
tls ,ssl ,security ,network security ,web security

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}