SSL versus TLS – What’s the difference?
SSL versus TLS
TLS (Transport Layer Security) and SSL (Secure Sockets Layer) are protocols that provide data encryption and authentication between applications and servers in scenarios where that data is being sent across an insecure network, such as checking your email (How does the Secure Socket Layer work?). 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 though, is there actually 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 (especially for web sites 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 for HIPAA-compliant communications. If that was not enough … POODLE certainly was. In fact, as a result of POODLE, SSL v3 was disabled on web sites all over the world and for many other services as well.
SSL v3.0 is effectively “dead” as a useful security protocol. Places that still allow its use for web hosting are placing their “secure web sites” 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 present in SSL v3.0 and TLS v1.0. For example, the BEAST attack that can completely break web sites running the older SSL v3.0 and TLS v1.0 protocols. The newer TLS versions, if properly configured, prevent the BEAST, other attack vectors, and provide many stronger ciphers and encryption methods.
As of the time of this writing (May, 2018), 11% of web sites still support SSL v3.0. However, a great majority 92% already support TLS v1.2+. Check the latest statics over at SSLLabs.
The trend is, of course, to deprecate the older protocols in favor of the new ones. For example, use of TLS 1.0 by web sites 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 recommends only 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 5 years old) that completely turning off TLS 1.0 and 1.1 support could cause a large disruption. As a result, we are seeing the transition to TLS 1.2 as being more gradual … where sites and systems that need it (for PCI and government work) leading the way, followed by those whose users are likely to have more recent computed systems. Likely, in the next several years, TLS 1.0 support across the internet will steadily decline. 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 setup an email program you may see separate options for “no encryption”, “SSL”, or “TLS” encryption of you transmission. This leads one to assume that TLS and SSL are very different things.
In truth, this labeling is a misnomer. You are not actually selecting which method to use (SSL v3 or TLS v1.x) when making this choice. 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 and that level is determined by the software installed on the server, how that is configured, and what your program actually supports.
If the SSL vs TLS choice is not SSLv3 vs 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 that 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 setup 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 first begin with an insecure “hello” to the server and only then 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 of this 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 and explicit or implicit connection to initiate security, and choose your 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 to 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).
- Use of either could result in a connection encrypted with either SSL v3 or TLS v1.0+, based on what is installed on the sever and what is supported by your program.
- Both methods of connection (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 both enable you to be sure that the server that you are communication with is the server you intend to contact and not some “middle man eavesdropper“. This is possible because servers that support SSL and TLS must have certificates issued to them by a trusted third party, like Comodo. These certificates verify that the domain name they are issued for really belongs to the server (all about SSL certificates). Your computer will issue warnings to you if you try to connect to a server and the certificate that it gets back is not trusted or doesn’t match the site you are trying to connect to.
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 the connections that your users make are as secure as possible. Using an excellent security certificate will also help a lot — e.g. one with 2048+ bit keys, Extended Validation, etc. You should avoid using SSL v3 and should use only strong ciphers, especially if compliance of any kind 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 it is supported by your server.
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 easily become a party line for eavesdroppers. Your data and your 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 do support TLS v1.2; our web sites are protected against the BEAST and POODLE attacks. 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 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 make plans 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 that will be used with TLS v1.3 are incompatible with previous versions of TLS
- Drop weak security. Many things knows known to be cryptographically weak such as MD5, RC4, and weak elliptic curves have been completely dropped, so that 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 is it 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.
Have a question? Ask Erik