SSL versus TLS – What’s the difference?

May 12th, 2018

SSL versus TLS

TLS (Transport Layer Security) and SSL (Secure Sockets Layer) are protocols that provide data encryption and authentication between applications and servers when that data is sent across an insecure network. The terms SSL and TLS are often used interchangeably or in conjunction with each other (TLS/SSL), but one is, in fact, the predecessor of the other. SSL 3.0 served as the basis for TLS 1.0, which, as a result, is sometimes referred to as SSL 3.1. With this said, is there a practical difference between the two?

See also our Infographic which summarizes these differences.

Which is more secure – SSL or TLS or TLS v1.x?

It used to be believed that TLS v1.0 was only marginally more secure than SSL v3.0, its predecessor. However, SSL v3.0 is very old, and attacks such as the POODLE vulnerability have shown that SSL v3.0 is now completely insecure (mainly for websites using it). Even before the POODLE was set loose, the US Government had already mandated that SSL v3 not be used for sensitive government communications or HIPAA-compliant communications. If that was not enough, POODLE certainly was. In fact, as a result of POODLE, SSL v3 was disabled on websites worldwide and for many other services.

SSL v3.0 is effectively “dead” as a helpful security protocol. Places that still allow its use for web hosting place their “secure websites” at extreme risk. Organizations that allow SSL v3 use to persist for other protocols (e.g., IMAP) should take steps to remove that support at the soonest software update maintenance window.

Subsequent versions of TLS — v1.1, v1.2, and v1.3 are significantly more secure and fix many vulnerabilities in SSL v3.0 and TLS v1.0. For example, the BEAST attack can completely break websites running the older SSL v3.0 and TLS v1.0 protocols. The newer TLS versions, if properly configured, prevent the BEAST and other attack vectors and provide many stronger ciphers and encryption methods.

As of this writing (May 2018), 11% of websites still support SSL v3.0. However, a significant majority, 92%, already support TLS v1.2+. Check the latest statistics over at SSLLabs.

The trend is, of course, to deprecate the older protocols in favor of the new ones. For example, the use of TLS 1.0 by websites that accept credit cards (and services used by the US government) must stop by June 30th, 2018. Instead, they must use TLS 1.1 with TLS 1.2+ strongly encouraged). As early as 2014, NIST (National Institute of Standards and Technology) revised its guidelines and recommended only the use of TLS 1.1+ for government communications. NIST does indicate that TLS v1.0 is OK for non-government communications, even in its latest 2018 draft updates. Everyone should use TLS 1.2 and 1.3 when possible. However, so many organizations still have older computers (more than five years old) that completely turning off TLS 1.0 and 1.1 support could cause significant disruption.

As a result, we see the transition to TLS 1.2 as being more gradual. Sites and systems that need it (for PCI and government work) are leading the way, followed by those whose users are likely to have more recent computed systems. TLS 1.0 support across the internet will steadily decline in the next several years. However, as we see with SSL 3.0, it will not go away in general for some time to come.

But wait: are not TLS and SSL different encryption mechanisms?

If you set up an email program, you may see different options for “no encryption,” “SSL,” or “TLS” encryption for transmission. This leads one to assume that TLS and SSL are very different things.

In truth, this labeling is a misnomer. When making this choice, you are not actually selecting which method to use (SSL v3 or TLS v1.x). You are merely selecting between options that dictate how the secure connection will be initiated.

No matter which “method” you choose for initiating the connection, TLS or SSL, the same level of encryption will be obtained when talking to the server. That level is determined by the software installed on the server, the configuration, and what the program supports.

If the SSL versus TLS choice is not SSLv3 versus TLS v1.0+, what is it?

There are two distinct ways that a program can initiate a secure connection with a server:

By Port (a.k.a. explicit): Connecting to a specific port means a secure connection should be used. For example, port 443 for HTTPS (secure web), 993 for secure IMAP, 995 for secure POP, etc. These ports are set up on the server, ready to negotiate a secure connection first and do whatever else you want second.
By Protocol (a.k.a. implicit): These connections begin with an insecure “hello” to the server and only switch to secured communications after the handshake between the client and the server is successful. If this handshake fails for any reason, the connection is severed. A good example is the command “STARTTLS” used in outbound email (SMTP) connections.

The “By Port” method is commonly referred to as “SSL” or “explicit,” and the “By Protocol” method is commonly referred to as “TLS” or “implicit” in many program configuration areas.

Sometimes, you have only the option to specify the port and if you should be making a secure connection or not, and the program itself guesses from that what method should be used. Many old email programs like Outlook and Mac Mail did that. In such cases, you need to know if the program will try an explicit or implicit connection to initiate security and choose the port appropriately (or else the connection could fail).

To Review: In email programs and other systems where you can select between SSL or TLS and choose the port a connection will be made on:

SSL means a “by port” explicit connection to a port that expects the session to start with security negotiation.
TLS means a “by protocol” connection where the program will connect “insecurely” first and use special commands to enable encryption (implicit).
Using either could result in a connection encrypted with either SSL v3 or TLS v1.0+, based on what is installed on the server and what is supported by your program.
Both connection methods (implicit and explicit) result in equally secure (or insecure) communications.

Sidebar: It is unclear why the “By Protocol” method is referred to as “TLS” as it could result in either TLS or SSL actually being used. It is likely because the folks who designed the SMTP protocol decided to name their command to switch to SSL/TLS in the SMTP protocol to “STARTTLS” (using “TLS” in the name as that is the newer protocol name). Then email programs started listing “TLS” next to this and “SSL” next to the old “By Port” option which came first. Once they started labeling things this way, that expanded to general use in the configuration of other protocols (like POP and IMAP) for “consistency.” I am not certain if this is the real reason, but based on my experience dealing with all versions of email programs and servers over the last 15 years, it seems very plausible.

Both methods ensure that your data is encrypted as it is transmitted across the internet. They also enable you to be sure that the server you are communicating with is the server you intend to contact and not some “middle man eavesdropper.” This is possible because servers supporting SSL and TLS must have certificates issued by a trusted third party. These certificates verify that the domain name they are issued for belongs to the server (all about SSL certificates). Your computer will warn you if you try to connect to a server and the certificate it gets back is not trusted or doesn’t match the site you are trying to connect to.

Should I choose TLS or SSL?

So then, should I choose TLS or SSL?

If you are configuring a server, you must install software that supports the latest versions of the TLS standard and configure it properly. This ensures that your users’ connections are as secure as possible. Using an excellent security certificate will also help a lot. Choose one with 2048+ bit keys, Extended Validation, etc. You should avoid using SSL v3 and use only strong ciphers, especially if compliance is required.

If you are configuring a program (especially an email program) and have the option to connect securely via SSL or TLS, you should feel free to choose either one, as long as your server supports it.

Note: many web browsers have special (usually hidden) preferences that allow you specifically enable/disable SSL v2, SSL v3, TLS v1.0, etc. In these cases you are actually telling the browser what versions of these security protocols you will allow your browser to use when establishing secure connections. We recommend turning off SSL v2 and SSL v3 (they provide no real security). A few web sites still support SSL v3 only; if you encounter one of these, please let them know that they are seriously behind the time and doing themselves and their visitors a serious disservice by pretending to provide safety while actually only providing broken, ancient encryption.

What happens if I do not select either one?

If neither SSL nor TLS is used, then the communications between you and the server can quickly become a party line for eavesdroppers. Your data and login information are sent in plain text for anyone to see; there is no guarantee that the server you connect to is not some middle man or interloper. For more on this, see the case for email security.

Does LuxSci support these security protocols?

SSL/TLS form the basis of client-server security used by LuxSci for all of its services. Our web servers do not support SSL v3.0 and support TLS v1.2. We use only strong, NIST-recommend ciphers for compliance reasons. We offer a variety of ports for connecting securely to POP, IMAP, and SMTP using both implicit and explicit methods for establishing TLS encryption. LuxSci also offers WebMail over SSL and provides SSL for web hosting clients.

To ensure the integrity and security of your data, LuxSci strongly recommends taking advantage of our secure capabilities, such as the enforced use of PGP, S/MIME, TLS, and email Escrow protocols.

What about TLS v1.3?

TLS v1.3 is the latest and greatest version of TLS. It became an internet standard on March 25th, 2018. According to NIST, organizations should plan to support TLS v1.3 by January 1st, 2020, or sooner.

TLS v1.3 brings many significant changes over TLS v1.2. Some of these include:

All new ciphers. The ciphers used with TLS v1.3 are incompatible with previous versions of TLS.
Drop weak security. Many things are known to be cryptographically weak, such as MD5, RC4, and weak elliptic curves, have been completely dropped, so it will be impossible to use them with TLS v1.3.
Drop seldom-used features. Features that are little used, like compression and “change cipher” ciphers, have been dropped to simplify and strengthen the protocol.
Faster. TLS v1.3 speeds up the client-server negotiation of security, making secure connections faster to initiate.
No Corporate/ISP Eavesdropping. With TLS v1.3, it is no longer possible for organizations to seamlessly monitor secure connections by passively decrypting and re-encrypting them.

What is next? Who knows, maybe “TLS v1.4” will start to include some of Google’s New Hope post-quantum algorithms.