SSL vs TLS: What’s the Difference
Making websites more secure is no small task, but there are a whole host of technical experts and internet enthusiasts who have willingly accepted the burden. The development of protocol specifications by the Internet Engineering Task Force (IETF) continues unabated and IETF writers have left us a clear paper trail that lays out their thoughts on the subject.
In this article we discuss two internet protocols that they've been working on for years that are crucial to website security: SSL and TLS.
What is SSL?
Secure Sockets Layer (SSL) is a protocol used to make internet communications secure. Its purpose is to allow users to transmit confidential information back and forth once a website is verified to be authentic and trusted. It sets up an encrypted session between the web browser and the server.
There have been three versions of SSL since its inception in the 1990s, SSL 1.0, 2.0, and 3.0, but those versions are now considered obsolete. SSL 3.0 was deprecated in 2015 as per RFC 7568, and all subsequent solutions should make use of the newer TLS protocol.
Yet, the name SSL has become so ingrained in internet protocol vocabulary that even TLS implementations are generally called SSL.
What is TLS?
Transport Layer Security (TLS) is an industry-standard cryptographic protocol that provides secure communications over the internet. The latest version of the protocol is TLS 1.3, which was published in 2018. Operating at the application layer, TLS is used to secure interactions between web browsers and servers. It's also used in other applications such as email and messaging.
When used over top of the HTTP protocol, an TLS/SSL certificate (often referred to simply as an SSL certificate) makes a web page secure, and the URL spelling changes from HTTP to HTTPS.
The Public Key Infrastructure (PKI)
TLS/SSL connections take advantage of the key exchange system that is part of the public key infrastructure (PKI). The components of the PKI all work together to create a level of trust between the browser and the server. The communication between the two is made possible by the existence of both a public key and a private key.
The private key remains securely held by the website server, while a public key is widely available for use by the public. To verify that the website is what it claims to be, a digital certificate is used to authenticate the identity of the website. The encryption algorithms associated with the certificate then encrypt the data for secure transmission.
How TLS/SSL Certificates and Certificate Authorities (CA) Work
So, how can you be sure that a website is authentic? The solution is found in industry-recognized certificate authorities (CA). These are the people who issue the TLS/SSL certificates, including the public/private key pairs. When your browser recognizes a digital certificate from a trusted certificate authority, you will be able to transact business without issues.
However, if the TLS/SSL certificate is not recognized, you may see a browser message like this one that says, "The security certificate presented by this website was not issued by a trusted certificate authority."
When a TLS/SSL certificate appears invalid, your browser will likely warn you or prevent you from accessing the website. Websites without certificates still exist and you can browse them, but most experts advise against doing any kind of business on these unsecure sites.
Key Differences Between SSL and TLS
SSL and TLS were both created for the same purpose: website security. Let's make clear here that both protocols fulfill the same job function. But what sets TLS apart from its predecessor SSL is that it does the job much better.
Nomenclature. Be prepared that whenever you read about SSL or SSL certificates online these days, the writer may actually be referring to the newer TLS technology. SSL and TLS share many similarities that may make some people think of them as one technology. Because they were developed on different tracks, they were given different names. But TLS could just as well be referred to as a higher version of SSL.
Separate history. At the risk of sounding like a history lesson, the first obvious difference is in the separate development of the two protocols. SSL was introduced by Netscape in 1994 after it became clear that there was inadequate security for data transmissions at the higher levels of the OSI model. The deficiencies of SSL eventually led to RFC 6176, prohibiting the use of SSL version 2.0.
There were similar complaints about version 3.0 later in RFC 7568. It was so bad that the RFC writer tells us, "Any version of TLS is more secure than SSLv3, though the highest version available is preferable." And the title of section 4 can't be more clear: "SSLv3 Is Comprehensively Broken". The document cites problems with the record layer and the key exchange as well as the protocol's limited capabilities and its security problems in general.
There are two current versions of TLS in use (as of this writing): 1.0 (1999) and 1.1 (2006). But Cisco tells us that they are discontinuing both versions March 31, 2020. The reasons for retiring them is outlined in IETF's draft document "Deprecating TLSv1.0 and TLSv1.1" (which does not have a number right now because it is not yet approved). The problems cited regarding TLS 1.0 and 1.1 include the use of older cipher suites, the use of SHA-1 for handshakes, the potential for misconfiguration, and lack of support for the two versions in widely used libraries.
RFC 5246 defines TLS 1.2, the next attempt to provide the most private and reliable internet connections possible. Many of the improvements discussed in the document address the deficiencies discussed in the previous paragraph. And the current version 1.3 goes even further. The goals of TLS include interoperability and extensibility along with security.
Handshake Protection. One important issue addressed in the development of SSL and the move to TLS was handshake protection. Message authentication using MD5 is apparently not a good idea, but that was what SSL 2.0 used. The problem is that there was no protection for a handshake message using MD5. This issue was corrected in SSL 3.0 and all later versions of TLS. So while this is a difference between SSL 2.0 and TLS, it is also a difference between SSL 2.0 and 3.0.
Cipher Suites. Developments of SSL and TLS took into account the various encryption algorithms in use and adopted a way to handle them called cipher suite. TLS does a much better job than SSL in dealing with algorithms, particularly newer and stronger encryption algorithms.
Correction of Flaws. Website security was virtually nonexistent before the advent of SSL. But while SSL might be better than nothing, it's fundamentally deficient when compared to TLS. The particulars of the latest version of TLS are too involved to cover here. But you can be sure that it offers significant advantages over the previous versions, not to mention SSL. You can also rest assured that the industry specification defining the successor to TLS 1.3 is already in the works. The folks at IETF apparently never rest.
The "POODLE" Attack
Adding insult to injury, hackers invented something called the "POODLE" attack (“Padding Oracle On Downgraded Legacy Encryption”) that could be triggered when websites automatically fall back from TLS to SSL 3.0. It's a man-in-the-middle attack that can make cypher text readable. Experts advise users both to disable SSL 3.0 capability in their browsers and to disable the fallback mechanism that facilitates the attack.
Whatever your particular specialty, every IT professional needs to know something about network security. Preparing for the CompTIA Security+ exam will give you an excellent foundation in the topics that are important to the protection of sensitive information on the internet such as SSL and TLS.
While sometimes we may tend to skim the surface, going deep into security issues can be rewarding both in terms of professional competence and career development. At any rate, gaining a good understanding of website security using TLS/SSL is highly recommended.
delivered to your inbox.