Inside Out Security Blog » Data Security » TLS vs SSL: What’s the Difference & How it Works

It’s a bird……It’s a plane…..It’s…….a cryptographic networking protocol? While they may not be from the planet Krypton, Transport Layer Security (TLS) and Secure Sockets Layer (SSL) take on the Superman-like task of safeguarding our private communications even in the face of the most determined adversaries. And just as the population of Metropolis seems to suffer from a chronic epidemic of face blindness that prevents them from realizing that Clark Kent and the flying alien who looks just like him are actually the same people, the tech industry has had a long and sometimes pedantic “TLS vs SSL” war of words when the two are in fact much the same thing. 

In this post, we’ll unravel the confusion behind some of these terms, look at the history that led to the whole “SSL vs TLS” mess in the first place, and learn how these technologies keep us safe online – even when using shared networks like a Wi-Fi hotspot.

Important Definitions to Know

Any discussion about security on the web can quickly turn into an alphabet soup of obscure acronyms and technobabble. However, the terms below are important enough to highlight. 

What is TLS?

TLS is the most commonly used standard for securing communications between two or more devices across a network. It aims to guarantee the confidentiality and integrity of information transmitted, even when the network links themselves may not be completely trusted. The most common use of TLS is to secure sessions between a Web browser and Web server, although the protocol is used in everything from VPNs to video chats. 

Version 1.0 of the TLS protocol was released in 1999. It was heavily based on the earlier SSL protocol originally developed by Netscape. The name change was intended to clarify that this was an open standard that any company or project could incorporate and not a proprietary product of Netscape (which at the time was still selling “Netscape Enterprise Server” web server software which used “SSL” for transport encryption). The open TLS standard has since been updated several times, most recently in 2018 with TLS 1.3.

What is SSL?

SSL was the first widely used technology for securing communications on the world wide web. Developed in the mid-1990s by a team at Netscape that included famed cryptographer Taher Elgamal, SSL helped lay the foundation for our modern Internet-centric lives. Initial versions of the protocol had several major weaknesses, but by SSL version 3.0 the protocol was helping enable a boom in e-commerce and other online activities that would have been impractical without encryption.  

Ciphers, Certificates, and HTTPS

TLS is intended to take on the superhero-level task of safeguarding our communications and transactions even in the face of the most technologically advanced adversaries. As such, the protocol uses a complex and ever-changing mix of underlying technologies that can be swapped in and out as weaknesses are discovered. Here’s a look at some of the most important:

Ciphers are the cryptographic algorithms that convert plaintext information into encrypted “ciphertext” that can only be viewed by authorized parties. Both SSL and TLS use a combination of ciphers known as a “cipher suite” to protect the message and protect the integrity and authenticity of a message. The mathematical functions of each algorithm are constantly being probed for weaknesses, and new ciphers have been added over the years as weaknesses in the older ciphers are discovered.

Certificates are another hugely important component of both TLS and SSL. They serve a couple of major purposes. First, they validate the identity of the site a user is attempting to connect to. Second, they contain a public encryption key that can be used to decode encrypted messages sent from the site. 

Hypertext Transfer Protocol Secure (HTTPS) is the secure version of the Hypertext Transfer Protocol (HTTP), the protocol that web browsers and web servers use to communicate with one another. TLS/SSL don’t actually alter the underlying mechanics of HTTP. Instead, they wrap the same sort of HTTP messages we’ve always used in an additional layer of encryption. HTTPS is, therefore, more of a way of referring to the combined use of HTTP and either TLS or SSL than a brand new protocol. 

The History of TLS and SSL

Many of the standards and protocols in use on the Internet today were originally conceived at a time when computer security was barely a passing thought. As a result, everything from the Internet Protocol (IP) used at the network layer to the Hypertext Transfer Protocol (HTTP) that forms the basis of the Web lack both encryption and authentication. This means that anyone sitting anywhere between you and a web server could potentially eavesdrop on or even manipulate traffic. While not much of an issue when all we were doing with our browsers was cruising around Geocities and sharing Star Trek ASCII art, the modern use of the web for everything from banking to doctor’s visits wouldn’t be feasible without some added security.

During the late 1980s and early 1990s, computer scientists and researchers from the academic, government, and commercial realms wrestled with how and where to implement encryption while maintaining compatibility with the networking infrastructure and applications already in wide use. A number of different schemes and protocols were dreamt up, but none of these early attempts gained widespread use. Many of the general concepts, however, went on to be used in SSL, and later TLS.

• 1986-1995: Various groups study the problem of protecting confidential information traveling over the network. Several techniques are proposed, but most Internet traffic is still sent in plaintext.
• 1995: Netscape introduces Secure Sockets Layer (SSL) as a means to secure Web traffic.
• 1999: Transport Layer Security (TLS) 1.0, based on SSL, becomes an open standard and the de facto choice for securing e-commerce and other important traffic.
• 2008: TLS 1.2 is released improving security and adding more cipher suites and the ability to better specify the order of the security algorithms used.
• 2012-2017: Growing concerns over surveillance and monitoring lead to a push to encrypt all Web traffic. In 2017, Google begins including SSL/TLS as a factor in search rankings.
• 2018: TLS 1.3 is introduced to provide even greater amounts of privacy. Some corporations and governments criticize the new standard as going a step too far.

Currently: TLS 1.2 is the minimum acceptable version of TLS to be used in production.

TLS vs SSL: Key Differences

While the confusion over naming might imply otherwise, there really never was a “TLS vs SSL” debate. Conceptually the two are quite similar, and TLS is simply a natural technical evolution of the earlier SSL protocols. The primary distinction lies in who authored and controlled the protocol; SSL originated within Netscape and was initially a proprietary offering, while TLS has been an open standard of the Internet Engineering Task Force (IETF) since version 1.0. 

From a technical standpoint, each iteration of TLS from version 1.0 to version 1.3 has addressed security concerns in its immediate predecessor, meaning that TLS 1.3 is considerably more secure than the final version of SSL. Other changes have included performance enhancements and the deprecation of old cipher suites that are no longer considered secure.

TLS and SSL Certificates

You might already be familiar with the term “SSL certificate”. In truth, digital certificates are just as important in TLS as they were in SSL, and the difference just comes down to our collective bad habits: by the time TLS was introduced, we’d already gotten used to saying “SSL certificate” and the term “TLS certificate” just never caught on. As if TLS vs SSL certificates weren’t confusing enough, both protocols technically use a standard known as X.509 certificates, although you’ll almost never hear this language used.

No matter what you call them, certificates operate in the same way and fulfill several critical roles in the overall security framework. First, they authenticate the identity of the certificate holder. When you connect to varonis.com, you can be sure you’re getting the authentic Varonis website because the server presented a certificate to your browser, which caused the browser to display a padlock icon in the address bar. You can verify this yourself by clicking on that little padlock:

Certificates are issued by an organization known as a certificate authority (CA). The Varonis certificate, in this case, was issued by GlobalSign. Web browsers come with a pre-installed list of trusted CAs, which themselves have a digital certificate signed by a root CA. Certificates can also be self-signed, but this will trigger a warning in the web browser and should never be used for a production website because authenticity can’t be established.

In addition to authentication, certificates enable a very interesting use of something called asymmetric encryption in both SSL and TLS. Asymmetric encryption is so named because two different keys are used for encrypting and decrypting data. Generally, one key is kept private while the other can be publicly shared. This model is in contrast to symmetric encryption, in which a single key is used for both encryption and decryption. Symmetric encryption is less resource-intensive than its asymmetric counterpart, but the key must be kept secret in order to maintain the privacy of the message. This presents a problem when keys need to be exchanged over an insecure or untrusted medium like the Internet. So, the developers of SSL/TLS had an idea to get the best of both worlds: Asymmetric encryption would be used to exchange a symmetrical key that’s unique to each browsing session. 

During an initial conversation known as a “handshake”, the client and server will decide which cipher suite to use and then use one of several asymmetric encryption algorithms to derive a unique symmetric key that will be used for the rest of the session. The use of asymmetric encryption during the handshake makes it very difficult to capture or guess the session key, even when an attacker might be eavesdropping on a network link. There are, of course, a few deeper technical details involved in this whole process, but the general concepts have remained the same since the earliest days of SSL. 

Should I Use TLS or SSL?

All versions of SSL proper are now considered deprecated and should not be used. Modern browsers will consider a connection made over SSL – or even an early version of TLS – to be insecure because numerous known vulnerabilities exist in these protocols. However, the terminology is still used very loosely, and you’ll still commonly hear people use the term SSL in reference to securing web communications. Indeed, it’s still far more common to hear the term “SSL certificate” used when describing the certificates used in public-key cryptography – even when they’re used alongside the most recent versions of TLS. 

Imprecise language aside, it’s important to disable support for all versions of SSL in your web server or other application. Failing to do so will cause you to be out of compliance with a wide variety of security standards, including PCI DSS. Beyond compliance considerations, SSL and early implementations of SSL contain flaws serious enough that you should not consider them sufficient to protect communications.

But Don’t Use Them Alone…

While TLS, and previously SSL, go a long way towards ensuring our communications stay private, they don’t provide overall security. Those little padlock icons in your browser’s address bar only verify that the connection is secure: no assumptions can be made of the content being delivered over that connection. Malware can and does in fact get delivered over TLS/SSL, and the use of encryption can even make it harder for security solutions to spot suspicious files. TLS/SSL are also singularly focused on data in transit, and won’t do anything to help secure data at rest.

As always, it’s best to look at security from many different angles. Using TLS to encrypt private data is a good idea, but organizations should also take steps to reduce their overall risk and follow best practices like updating operating systems and running endpoint security software.