When it comes to internet security, TLS vs SSL is an important topic of conversation. The problem is that many people get confused between the two and don’t understand the difference between TLS and SSL. So what are they and how do they work? This article sets out to help you find your way through the maze.
Transport Layer Security (TLS) and Secure Socket Layers (SSL) are protocols that provide authentication and encryption when you are transferring data between devices on a network or webserver. TLS is now considered the standard for authentication, with serious vulnerabilities having been brought to light in SSL during the early 2000s following a number of high-profile exploits.
The protocols are different, but the confusion for many people comes in the fact that the terms TLS and SSL are used interchangeably. People say SSL when they actually mean TLS. Today, TLS is the encryption standard that everyone uses, and is most often used alongside other internet protocols such as HTTPS, SSH, FTPS, and secure email.
When it comes to looking at TLS vs SSL, it’s important to understand that SSL is the older protocol. It was developed by Netscape and was first seen in 1995, after which it went through a rapid progression as a number of vulnerabilities were found in the early versions—it had reached version 3.0 (SSLv3) by 1996. Meanwhile TLS appeared on the scene in 1999 as a new—more secure—version of SSL based on SSLv3.
In 2004, the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack crept in under the radar and rendered SSLv3 dangerously insecure.
The attack targeted browsers that relied on SSLv3 for encryption and authentication. Although TLS was widely used at the time, many browsers would default to SSLv3 if a TLS connection was unavailable. An attacker could break into a communication session and force the browser to use SSLv3. From here they were able to take advantage of a design flaw in SSLv3 which meant that padding data at the end of a block cipher could be changed so that the encryption cipher became less secure each time it was passed between devices.
To prevent the attack, administrators needed to check that their server software supported the latest version of TLS and that is was correctly configured.
In essence TLS consists of two parts:
Originally TLS v1 was touted as being only slightly more secure than SSLv3. Today, SSLv3 is considered dated and attacks such as the POODLE vulnerability (as explained above) have shown it to be critically insecure.
The discovery of POODLE led directly to SSLv3 being disabled for websites and services globally. This has effectively rendered it dead as a security protocol. So, if you haven’t disabled it already you should make sure you take steps to remove it as soon as possible. If you don’t know whether your site still uses SSLv3 you can check using this free tool: https://www.ssllabs.com/ssltest/
More recent iterations of TLS—v1.1, v1.2, and v1.3—have addressed many of the vulnerabilities in SSLv3 and TLSv1. Indeed, many believe it is now time to also ensure that any instances of TLSv1 have been deactivated. Use of TLSv1 by websites accepting credit cards or services used by the US Government had to stop by 30th June 2018. Instead, they must now use a minimum of TLSv1.1, with TLSv1.2 or higher being strongly recommended.
Regardless of this, there are many sites out there using old or insecure versions of SSL. You can see the figures changing on a daily basis at https://www.ssllabs.com/ssl-pulse/
There are two important ways your site will benefit from using encryption to protect sensitive data.
First, it will prevent intruders (whether malicious hackers or benign sources like ISPs or ad networks) from tampering with communications between your website and web browsers. Second, you can prevent intruders from passively listening to communications with your server.
The importance of these should not be underestimated, especially for sites that need to build user trust, such as ecommerce sites where credit card data is being handled.
However, SSL/TLS protocols are not without their drawbacks.
TLS can slow your site down. The handshake is resource-hungry, as it uses asymmetric encryption to establish a session key. It also adds complexity to your server management as you have to get an SSL certificate installed on your web server and maintain the validity of that certificate.
An SSL certificate is a small data file that is installed on your web server and links a cryptographic key to your organization’s details (including the name of the holder, serial number and expiration date, a copy of the certificate holder’s public key, and the digital signature of the certificate-issuing authority). This allows a secure connection to be made from a web server to a browser.
However, discussing pros and cons is becoming irrelevant as Google has now cracked down on website security. All websites with text input fields must have an SSL certificate or Google now flags website as not secure with a red caution sign next to their URL.
There are three main types of SSL certificates that offer different levels of trustworthiness and range in price and complexity. These include:
For a website to have a Domain Validation (DV) certificate a company must prove that they either own the domain or are the main administrator for it. Once the certificate has been acquired it enables a secure connection to be established with the website; however, it does not contain information about the organization. This is a very quick certificate to get as it requires no documentation to be sent or verified. As such it offers the lowest entry level of validation and is therefore not suitable for companies that require a significant level of trust, such as anyone in ecommerce.
The next level up from the DV certificate is the Organization Validation (OV) certificate. Once installed, the OV certificate enables the website to not only confirm that the connection to the domain is secure, but also that it definitely belongs to the organization in the certificate. If your site has either a DV or OV certificate, the browser displays a padlock with the word Secure and the letters HTTPS at the start of the URL in the address bar. There is quite a lot of documentation that needs to be checked with an OV certificate, so it can take a number of days to be issued.
The certificates that offer the highest are the Extended Validation (EV) certificates. This is the most complex certificate to acquire as it requires the owner of the website to go through a global standard identity verification process, ratified by the Certificate Association (CA)/Browser forum. This is so they can prove they have the exclusive rights to use a domain. During the process they will also be expected to prove their legal, operational, and physical existence. EV certificates are the most trusted by browsers, and so accordingly are also the most costly. Depending on the type of browser being used, details of the certificate can be viewed by clicking on the company name in the address bar.
To get an SSL certificate companies can either self-certify, where a webmaster issues and signs the certificate and generates cryptographic keys, or they can purchase one from a trusted certificate authority (CA). Self certification will still mean that the site is shown as not trusted, so it is worth the extra time and cost of going through one of the many CAs in the market.
Read through our blog for other information regarding TLS and SSL authentication methods.
Get the latest MSP tips, tricks, and ideas sent to your inbox each week.