Editor's Note: This post was originally published in July 2016 and has been updated by GlobalSign Senior Product Marketing Manager Patrick Nohe to reflect the latest changes in the evolution of SSL.
Unless you work with it regularly, there’s a good chance that you don’t know the difference between SSL (Secure Sockets Layers) and TLS (Transport Layer Security). And this industry doesn’t do you many favors by colloquially referring to TLS as SSL. There’s been four iterations of the TLS protocol. SSL has been (or is supposed to be) entirely deprecated. So, what’s the difference between SSL and TLS?
You’re about to find out.
A Brief History of SSL and TLS
SSL and TLS are both cryptographic protocols that provide authentication and data encryption between servers, machines, and applications operating over a network (e.g. a client connecting to a web server). In reality, SSL is only about 25 years old. But in internet years, that’s ancient. The first iteration of SSL, version 1.0, was first developed in 1995 by Netscape but was never released because it was riddled with serious security flaws. SSL 2.0 wasn’t a whole lot better, so just a year later SSL 3.0 was released. Again, it had serious security flaws.
At that point, the guys at Consensus Development took a crack at it and developed TLS 1.0. TLS 1.0 was incredibly similar to SSL 3.0 – in fact it was based on it – but still different enough to require a downgrade before SSL 3.0 could be used. As the creators of the TLS protocol wrote:
“The differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough that TLS 1.0 and SSL 3.0 do not interoperate.”
Downgrading to SSL 3.0 was still dangerous, though, given its known, exploitable vulnerabilities. All an attacker needed to do to target a website was downgrade the protocol to SSL 3.0. Hence, the birth of downgrade attacks. That ended up being the nail in the coffin for TLS 1.0.
TLS 1.1 came out seven years later in 2006, replaced by TLS 1.2 in 2008. That hurt TLS 1.1 adoption as many websites simply upgraded from 1.0 to TLS 1.2. We are now at TLS 1.3, which was finalized in 2018 after 11 years and nearly 30 IETF drafts.
TLS 1.3 makes significant improvements over its predecessors and right now major players around the internet are pushing for its proliferation. Microsoft, Apple, Google, Mozilla, and Cloudflare all announced plans to deprecate both TLS 1.0 and TLS 1.1 in January 2020, making TLS 1.2 and TLS 1.3 the only game in town.
At any rate, we’ve been using TLS for the past couple decades. At this point, if you’re still using SSL you’re years behind, metaphorically living in a forlorn era where people still use phone lines to dial on to the internet.
Should You Be Using SSL or TLS?
Both SSL 2.0 and 3.0 have been deprecated by the Internet Engineering Task Force, also known as IETF, in 2011 and 2015, respectively. Over the years vulnerabilities have been and continue to be discovered in the deprecated SSL protocols (e.g. POODLE, DROWN). Most modern browsers will show a degraded user experience (e.g. line through the padlock or https in the URL bar, or other security warnings) when they encounter a web server using the old protocols. For these reasons, you should disable SSL 2.0 and 3.0 in your server configuration, and while you’re at it – go ahead and deprecate TLS 1.0 and TLS 1.1, too.
According to a recent WatchGuard survey, nearly 7% of the Alexa Top 100,000 still support SSL 2.0 and/or SSL 3.0. So those sites are still out there in abundance.
Certificates Are Not the Same as Protocols
Before anyone starts worrying that they need to replace their existing SSL Certificates with TLS Certificates, it’s important to note that certificates are not dependent on protocols. That is, you don’t need to use a TLS Certificate vs. an SSL Certificate. While many vendors tend to use the phrase “SSL/TLS Certificate,” it may be more accurate to call them “Certificates for use with SSL and TLS," since the protocols are determined by your server configuration, not the certificates themselves.
That goes for encryption strength, too. Many certificates advertise encryption strength, but truly it’s the capabilities of the server and the client that determine that. At the beginning of each connection, a process called a handshake occurs. During this process, the client authenticates the server’s TLS certificate and the two decide on a mutually supported cipher suite. Cipher suites are a collection of algorithms that all work together to securely encrypt your connection with that website. When the cipher suite is negotiated during the handshake, that’s when the version of the protocol and the supporting algorithms are determined. Your certificate just facilitates the process.
Historically there have been four algorithms in a cipher suite:
- Key Exchange
- Digital Signature
- Message Authentication
- Hashing Algorithm
(If that seems a little in the weeds, it won’t in a second when we discuss the differences between SSL and TLS.)
For now, it’s likely you will continue to see certificates referred to as SSL Certificates because at this point that’s the term more people are familiar with. We’re beginning to see increased usage of the term TLS across the industry, and SSL/TLS is a common compromise until TLS becomes more widely accepted.
Are SSL and TLS Any Different Cryptographically?
Yes. The difference between each version of the protocol may not be huge, but if you were comparing SSL 2.0 to TLS 1.3 there would be a canyon between them. At its heart, the concept is the same through each version. It’s just the way the different protocols go about accomplishing the task of encrypting connections that diverges.
Each newly released version of the protocol came and will come with its own improvements and/or new/deprecated features. SSL version one was never released, version two did but had some major flaws, SSL version 3 was a rewrite of version two (to fix these flaws – with limited success) and TLS version 1 an improvement of SSL version 3. Between TLS 1.0 and 1.1, the changes were minor. TLS 1.2 brought some significant changes and TLS 1.3 has refined and streamlined the whole process.
It’s worth noting here that SSL and TLS simply refer to the handshake that takes place between a client and a server. The handshake doesn’t actually do any encryption itself, it just agrees on a shared secret and type of encryption that is going to be used. An SSL handshake uses a port to make its connections. This is called an explicit connection. Port 443 is the standard port for HTTPS, but there are 65,535 ports in all – with only a few dedicated to a specific function.
TLS, conversely, begins its connections via protocol. This is called an implicit connection. The very first step of the handshake – the act that commences it – is called a client hello. With TLS this is sent via an insecure channel and the connection switches to port 443 (or the port you’ve designated) once the handshake has begun.
Traditionally, the handshake has involved several roundtrips as authentication and key exchange take place. With SSL, this added latency to connections. That’s where the myth originated that SSL/HTTPS slows down your website. Each new iteration of the protocol has worked to reduce the latency added by the handshake. By TLS 1.2, it was proven that HTTPS was actually FASTER than HTTP owing to its compatibility with HTTP/2.
TLS 1.3 has refined the handshake even further. It can now be accomplished with a single roundtrip and enables Zero roundtrip resumption (0-RTT). Part of the way this was done was by reducing the number of cipher suites it supports, from four algorithms to two.
Now it’s simply a bulk encryption (symmetric/session) algorithm and a hashing algorithm. The key exchange and digital signature negotiations have been removed. Key exchange is now performed using a Diffie-Hellman family, which both enables perfect forward secrecy by default and allows the client and server to provide their portion of the shared secret on their first interaction. That first interaction is now encrypted, too, shutting the door on a possible attack vector.
For more information on the new features released in TLS 1.3, visit the Cloudflare blog.
Disabling SSL 2.0 and 3.0 and TLS 1.0
If you’re not sure if your servers are still supporting SSL protocols, you can easily check using our SSL Server Test. For instructions on how to disable SSL 2.0 and 3.0 on popular server types, including Apache, NGINX and Tomcat, check out our related support article. If you still need to disable TLS 1.0, we can help you with that, too.
So, what's the difference between SSL and TLS? In polite conversation, not much – and many people continue to use the terms SSL and TLS interchangeably. In terms of your server configuration though, there are some major architectural and functional differences. And those differences are the space between vulnerabilities, outdated cipher suites, browser security warnings – and a secure server. When it comes to your servers, you should only have TLS protocols enabled.
Have more questions about SSL/TLS configuration and best practices? Let us know in the comments; we’re happy to help!
