Transport Layer Security (TLS) is the latest version of the Secure Socket Layer (SSL) protocol. Both protocols ensure data privacy and authenticity over the internet. These widely used protocols provide end-to-end security by applying encryption for web-based communication. However, despite the similarities of TLS and SSL, they have significant differences, too. Show This article explains how the TLS and SSL encryption protocols work, their importance, how they differ, and why it's the right time to switch to TLS protocol. The Historical Background of TLS and SSLThe Internet Engineering Task Force (IETF), the organization responsible for developing internet standards, published Request for Comments (RFC-1984), recognizing the importance of personal data protection in the growing internet. The Netscape Communication Corporation introduced SSL to secure web communication which underwent multiple upgrades. The SSL 1.0 version was never released due to security flaws, and SSL 2.0 was the first public release by Netscape in 1995. However, due to security vulnerabilities and drawbacks, it was replaced by another SSL version 3.0 in November 1996. The latest SSL version is also not in use due to its insecurity against the POODLE attack in October 2014 and was officially deprecated in June 2015. TLS was released in 1999 as an application-independent protocol: an upgrade to SSL version 3.0 made by Internet Engineering Task Force (IETF). The idea was to implement TLS over TCP to encrypt applications using FTP, IMAP, SMTP, and HTTP protocols. For instance, HTTPS is a secure version of HTTP as it implements TLS to ensure safe data delivery by avoiding content alterations and eavesdropping. Communication between parties (e.g., your computer browser and a website) initiates by identifying if it will incorporate TLS/SSL protocol or not, such that the client can specify the use of TLS encryption either by:
In the meantime, a website requires a TLS/SSL certificate installed on its hosting server to use the protocol. A trusted third party issues the certificate that binds the public key to the domain that owns the private key and enables it to encrypt/decrypt the communication. After agreeing on using TLS/SSL for client-server communication, it proceeds to perform the handshake. The handshake establishes the specifications required to exchange messages. The following section summarizes the series of information exchanges to enable TLS/SSL connection:
If the browser can not validate theTLS/SSL certificate, it returns an error of "Connection is not Private." After establishing the decryption method during the handshake, the record protocol uses symmetric encryption for communication for the entire session. Besides, the record protocol also appends the message with the HMAC for TLS and MAC for SSL to ensure data integrity. Hence, the protocols accomplish three fundamental goals of security:
As mentioned earlier, the main difference you notice between both protocols is how they establish connections. TLS handshake uses an implicit way of establishing a connection via a protocol, while SSL makes explicit connections with a port. Irrespective of all other differences, the fundamental feature that differentiates both TLS/SSL connections is the use of a cipher suite that decides the overall security of the connection. The essential part of a TLS/SSL connection is to agree on a cipher suite that defines a set of algorithms for key exchange, authentication, bulk encryption, and a hash-based message authentication code (HMAC) or message authentication code algorithms, etc. for a particular session. Each TLS/SSL version supports a different set of cipher suites for the communication session. Hence, each cipher suite supports its own set of algorithms that improves security and overall connection performance.
TLS encryption is now a standard practice to secure web applications or in-transit data from eavesdropping and tampering. It's unrealistic to assume TLS as the most secure protocol as it has been prone to breaches such as Crime and Heartbleed in 2012 and 2014, but it has shown a lot of improvements in terms of performance and security. TLS is replacing SSL, and almost all of the SSL versions are now deprecated due to its known vulnerabilities. Google Chrome is one such example that stopped using the SSL 3.0 version back in 2014, and most modern web browsers do not support SSL at all. TLS helps secure sensitive on-transit information such as credit card details, emails, voice over IP (VOIP), file transfer, and passwords. Even though both certificates perform the task of in-transit data encryption, they differ in functionality and are not interoperable. It is important to note that TLS is referred to as SSL only because SSL is the most commonly used terminology, and the presence of a certificate does not guarantee the use of the TLS protocol. Besides, you do not need to worry about changing SSL to TLS certificates as all you need to do is install the certificate on the server as it supports both protocols and decides which one to use. 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 TLSSSL 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.”
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. Certificates Are Not the Same as ProtocolsBefore 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:
(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.0If 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! |