SSL versus TLS

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?

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 getting very old and recent developments, 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 is being 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 as placing their “secure web sites” at 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 and v1.2 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 on 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.

Unfortunately, even now a majority of web sites do not use the newer versions of TLS and permit weak encryption ciphers. Check how well your favorite web site is configured.

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

If you setup an email program you will often 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:

1. 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.
2. 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 from SSL or TLS together with the port a connection will be made on:

1. SSL means a “by port” explicit connection to a port that expects to the session to start with security negotiation
2. TLS means a “by protocol” connection where the program will connect “insecurely” first and use special commands to enable encryption (implicit).
3. 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.
4. Both methods of connection (implicit and explicit) result in equally secure 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 Verisign or Thawte.  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 version 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 preference areas 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).  Some web sites may 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 MySQL and 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.

Update for July, 2016: What about TLS v1.3?

TLS v1.3 is still an Internet Draft and the specifications for what will finally be in it and how exactly it will differ from v1.2 are not finalized.    However, we do know some of things that v1.3 is going to provide.  These include the complete removal of things that are known to be cryptographically weak such as MD5, RC4, and weak elliptic curves; dropping support for seldom-used features like compression and “change cipher” ciphers; and adding new elliptic curves.

Once TLS v1.3 is finalized and stable in the standard TLS libraries (e.g. openssl), I imagine we will see a strong push to move further away from TLS v1.0 and v1.1 and to use v1.2 and v1.3 exclusively.  This seems to be the rapid trend.  Who knows, maybe TLS v1.4 will start to include some of Google’s New Hope post-quantum algorithms.

Share on FacebookPlus on Google+

SUBSCRIBE MORE CONTENTS