Overview of TLS and SSL

Unless you’ve had experience with information security or an adjacent field that relies on its importance, there’s a good chance you’re not much familiar with network communication security methods, in particular SSL (Secure Sockets Layers) and TLS (Transport Layer Security). Both SSL and TLS are communication protocols that help you securely authenticate and transport data over a computer network. But how does it work, and what’s the difference between SSL and TLS?

SSL/TLS are commonly referenced together as both arose to further privacy, security, and data integrity in regards to computer network communications. SSL/TLS are cryptographic protocols, and the etymology of “cryptography” explains pretty well its intended function: “kryptos” being Greek for “hidden/secret”, and “graphein”, a verb meaning “to write”. So SSL/TLS are protocols facilitating the private/secret writing/communication of data from one source to another.

+++

One of the primary functionalities of SSL/TLS is encryption/decryption. Encryption is essentially scrambling data sent so unintended parties aren’t able to intercept, understand, and potentially use that data for nefarious ends. But at the same time, the intended recipient also needs to be able to read and understand the message, hence where decryption comes in, the unscrambling of that data by the intended recipient.

It’s a bit simplified, but encryption could be likened to what I used to do with my buddies in elementary school: we’d create notes to one another using a cipher, most often the alphabet reversed (A = Z, B = Y, C = X, etc…). So if I was bored, I could toss my friend a note that said:

“SVOOL”

Which, when he walked it back (because he knew the cipher, the alphabet in reverse) would read:

“HELLO”

(I’m sure that got past every teacher I ever had).

With SSL/TLS, there’s a lot more math involved though. Like, A LOT. And we’re talking about computer-performed math: algorithms, asymmetric ciphers, digital signatures, all of which is intended to take it to the point where it’s uncrackable (or as near to that as possible). However complicated SSL/TLS encryption/decryption is, the premise is the same: unless you’re in on it, you’re only going to get a bunch of gibberish.

+++

Another function of SSL/TLS involves authentication, the act of verifying that the computer/entity you’re communicating with is the one you’re intending to. This is important because with computer network communications, it’s very rare that you’re in total control of the entire route those communications take.

For example, if I try to reach Google in my web browser, there’s not a direct Ethernet cable running from my house to a Google server. My computer goes through my router and then through my Internet Service Provider. My ISP might route that traffic to Salt Lake City, then Phoenix, and finally on to Google in California.

Since I don’t control the full route, without peer authentication it’s not entirely impossible for a malicious entity to intercept those communications and pretend to be Google. So when my computer says “Hey I want to talk to Google”, I hear back “Yeah, I’m Google, what’s up?”. And then I tell Google “I’d like to order a pizza, here’s my credit card number.”

Well, without peer identity authentication, it’s possible I wasn’t actually talking to Google and I’ve just given my credit card number to some guy in a van outside my house who’d compromised my Wi-Fi. As such, authentication is another important aspect of SSL/TLS as it allows us to verify that we’re talking with who we’re meaning to talk with.

With SSL/TLS, peer authentication happens largely via the use of CAs (certificate authorities). Essentially certificate authorities are trusted entities that generate digital certificates proving the authenticity of a party in possession of that certificate. These digital certificates are offered by trusted companies (some of the largest CAs include Symantec, DigiCert, GoDaddy, Sectigo, etc…) which vouch for, audit, manage, and can revoke certificates they give out.

+++

The last functionality of SSL/TLS we’ll touch on is data integrity/validation. Essentially data integrity is related to ensuring what you send is received by the recipient exactly how you intended it (or vice versa). Data integrity verification is pretty widespread across many communication protocols and certainly not unique to SSL/TLS, but still worth mentioning.

Data integrity validation was initially critical in case a computer/router/network glitched while transmitting data and missed something. But there are certainly serious security implications.

In the earlier example where my credit card number was stolen, let’s say the guy in the van was a bit less ambitious and a bit more hungry: instead of stealing my credit card number he intercepted the communications and only modified what I sent and passed it then on to Google. So I order a pizza to be delivered to my house, paid for by my credit card. The gentleman in the van intercepts the communications, changes the packets sent to Google, deletes my address from the pizza delivery and puts his own. So I paid for the pizza, but it was delivered to his address.

Data integrity aims to ensure this can’t happen. Every piece of information sent is sort of added together to create a message integrity check; if this doesn’t match, the communication is invalid.

Again, many network communication protocols use methods for ensuring data integrity, but it is worth mentioning SSL/TLS do so as well.

+++

As previously mentioned, SSL/TLS are typically referred to pretty interchangeably but they both perform very similar functions. And actually, TLS could essentially be considered a more recent version of SSL, as TLS fixes some security vulnerabilities in the earlier SSL protocols.

In order to understand the relationship, it may help to look at the timeline of when they were created and what happened with releases.

SSL 2.0 was first released in February 1995 (SSL 1.0 was never publicly released because of security flaws). Although SSL 2.0 was publicly released, it also contained security flaws and was quickly replaced by SSL 3.0 in 1996. Then, in 1999, the first version of TLS (1.0) was released as an upgrade to SSL 3.0. Since then, there have been three more TLS releases, with the most recent release being TLS 1.3 in August 2018. (Kinsta).

Here’s the full history of SSL and TLS releases:

• SSL 1.0 – never publicly released due to security issues.

• SSL 2.0 – released in 1995. Deprecated in 2011. Has known security issues.

• SSL 3.0 – released in 1996. Deprecated in 2015. Has known security issues.

• TLS 1.0 – released in 1999 as an upgrade to SSL 3.0. Planned deprecation in 2020.

• TLS 1.1 – released in 2006. Planned deprecation in 2020.

• TLS 1.2 – released in 2008.

• TLS 1.3 – released in 2018.

So, despite the name change, TLS can be considered a pretty natural continuation of and improvement on SSL.

+++

To recap, both TLS and SSL are protocols that help you securely authenticate, transport, and validate data over computer network communications and as such are critical for sensitive transmissions. For example, if you’re processing credit card payments on your website, TLS would help you securely process that data so that malicious actors can’t get their hands on it.

As for which one to use, both public releases of SSL are deprecated in large part because of known security vulnerabilities in them. SSL and earlier versions of TLS are not fully secure protocols in 2020 and beyond. SSL got the ball rolling in a good way, TLS 1.0 and TLS 1.1 kept things going, but now it’s time for TLS 1.2 or higher to shine.