SSL vs TLS
SSL and TLS are protocols designed to enable the secure transport and authentication of data on the Internet. But how far do SSL and TLS differ?
If you're beginning to dive into web development, you've likely heard the terms "SSL" and "TLS". The two acronyms are mentioned in many textbooks and tutorials. In the past several years, however, the difference between the two has become clearer as more and more vulnerabilities in both have surfaced.
We will show you the main differences between the two protocols and what you should watch out for in the future.
How does SSL and TLS data protection work?
When you install a TLS/SSL certificate on your web server, you get a private key and a public key that let your server encrypt and decrypt data and authenticate your server.
Now when someone visits your site, their web browser looks for your site's TLS/SSL certificate. The browser then performs a so-called "handshake" to authenticate your server as well as to check if the certificate is still valid. If the certificate is not valid, this may cause your visitor to receive an error message and leave your website.
If your visitor's browser can determine the validity of your certificate as well as authenticate your server, an encrypted connection is established between your server and the visitor's server to transport the data securely.
Once a visitor's browser determines that your certificate is valid and authenticates your server, it essentially establishes an encrypted connection between them and your server to securely transport data.
The chronology of SSL vs TLS
To truly understand the difference between SSL vs TLS, it's important to know some of the basic histories behind the two. For those a bit more seasoned with web technologies, you may remember that the very first public release of either was SSL version 2. This shipped with the Netscape browser in March of 1995!
To date, this is the very first shipment of a browser with built-in security protocols. There were likely private versions that only researchers had access to before this time.
Microsoft's failed SSL monopoly attempt
Just months later, in October 1995, Microsoft came out with its own rendition of SSL v2. It was called "Private Communication Technology" and added some security features to Netscape's SSL v2. Though it actually would have been viable, only Microsoft products ended up using this proprietary technology. Eventually, it became so obsolete that even Microsoft stopped using it.
SSL v3
Almost immediately after SSL v2 was released, researchers began poking holes in it. It became clear very quickly that there were gaping security issues in it that had to be fixed. Netscape responded by creating a much sturdier and more secure SSL v3 in November of 1995.
Because SSL was the first method through which users could securely submit information on unsecured and monitored networks, this is what effectively enabled the "dot com era" to begin in the late 1990s.
Moving to TLS
1999 is when the confusion many people experience to this day regarding the difference between SSL vs TLS began. In 1996, a group of researchers began to make an international standard for SSL v3. Up to this point, it had largely been contained to groups of researchers and high-tech companies, and the goal was to ultimately make the technology available and accessible to the public at large.
Although the researchers began the creation of these standards in 1996, they didn't finish until 1999. There were some allegations of plagiarism, as the protocol they came up with ended up being pretty much identical to the SSL v3 protocol that Netscape had put out already. Nonetheless, these specifications were publicly released in 1999.
Using the influence it had recently obtained in the world of computing, Microsoft ensured that the name was changed from SSL. This was largely due to marketing reasons, since even though SSL v3 was open source, its name was heavily associated with Netscape. They insisted that these specifications, nearly the same as those associated with SSL v3, were called something else: Transport Layer Security - TLS 1.0.
Subsequently, there were three more TLS releases. The most recent version - TLS 1.3 - was released in August 2018 (we will go into more detail about the development of TLS later).
The rapid evolution of TLS
From 1999 on, TLS continued to rapidly develop. In 2006, researchers identified a complex cyberattack known as the BEAST attack later on. Though it was patched through TLS v1.1 released in 2006, it was still a viable vulnerability, as some users still allowed "downgrade attacks" to occur; these happen when a website demands that a browser use a lesser version of TLS or SSL.
In August 2008, a long-awaited TLS 1.2 came out. The need for CBCs (blocked ciphers) was taken out in this version of TLS. Though hardly anyone seemed to care at the time, this upgrade would prove to be so critical that certain browsers wouldn't even allow their users to keep any TLS version below 1.2 on!
SSL makes a comeback
After TLS 1.2 came out, even in 2009, SSL v3 remained essentially the same that it was when TLS 1.0 was released in 1999. A company called SSL Labs decided to resurrect the SSL protocol. Their sole mission was to assess the true security of SSL and improve it.
So, what was the actual difference between SSL vs TLS in 2009? Essentially, researchers had reliably updated the TLS security protocol, while SSL had been neglected. Nonetheless, some browsers allowed users to still utilize SSL v3 in their browsers, making it quite easy for cybercriminals to steal information from them.
SSL Labs findings
When SSL Labs came onto the scene, other groups and companies took a new interest in further developing SSL. Remember, TLS 1.0 was pretty much a fork of SSL v3 and had been further developed at this point.
A few improvements were immediately added to SSL v3, but the protocol was still called the same thing. Likely the single largest item output by SSL Labs was a large presentation on the current state of SSL. This was presented at the United States' Black Hat Conference in 2010. You can view the slides in their entirety TLS. The presentation went over all of the vulnerabilities that were still present in SSL vs TLS.
The FireSheep revolution
It had never been a secret that information submitted over non-secured protocols and protocols with very weak security were vulnerable to being stolen. However, a group of developers released a Firefox extension called FireSheep. This allowed almost anyone to steal credentials over wireless networks and was the final push for companies to align with current SSL standards to protect their own users.
The post-FireSheep era
After 2010, SSL development accelerated even more. In 2010, taking the recommendations of SSL Labs, every major browser developer deprecated SSL 2.0 (essentially the same as SSL v3). This protocol had been "broken" for quite awhile, but alarmingly, 54% of servers online in 2011 still allowed SSL 2.0.
The Snowden leaks
In 2013, Edward Snowden leaked thousands of classified, internal NSA communiques. Some of these contained information on alleged techniques the NSA used to monitor plaintext communications. It also showed how the NSA had developed internal techniques to break TLS 1.0 and 1.1 and SSL 2.0. These reports were a wakeup call for the security community and underscored the importance of creating truly secure protocols.
As a result, TLS 1.3 development began in August 2013. Though TLS 1.2 is still seen as "secure", researchers have realized that this will not stay true for too long after the Snowden leaks.
Fast-forwarding through SSL research
The key difference between SSL vs TLS is that the two were essentially identical in 1999; from there, TLS development took off for awhile. Then, SSL development began to surpass TLS development.
OpenSSL formed, which is an open-sourced SSL certificate creation and utilization tool. Of course, Google and Microsoft very quickly made their own implementations and put these into their browsers officially. In 2015, all major browsers disabled "fallbacks" to old TLS versions (1.0 and 1.1) that cybercriminals had previously used to steal information.
SSL v3 retired
SSL v3 was officially retired after a group of researchers successfully performed the POODLE attack on it. This attack enabled certificate spoofing and hijacking, which effectively made the protocol useless. At this point, browser vendors began making their own versions of SSL they claimed were more secured.
Over the years, different vulnerabilities in different security suites were found, and these suites were then retired. TLS 1.3 was eventually released in 2018, taking all of this research put into SSL into account.
Why do people still talk about the SSL certificate even though SSL is obsolete?
As you learned above, TLS is the newer version of SSL.
So why do people still stumble over the term SSL certificate? After all, TLS is the modern security protocol.
Basically, this is a branding issue. Many large certificate providers still refer to their certificates as SSL certificates, so the naming convention remains.
Thus, there is not just one SSL certificate or one TLS certificate. In fact, all "SSL certificates" are actually SSL/TLS certificates.
The status in 2022
We've looked extensively into the history of SSL vs TLS now, but where do the two technologies stand now? Most modern web browsers have not supported SSL v2 and v3 for a long time. In addition, the older TLS versions (TLS 1.0 and 1.1) are no longer considered secure. For example, Microsoft disabled TLS 1.0 and 1.1 in September 2022.
Though many certificate vendors refer to them as "SSL/TLS certificates", SSL and TLS are both simply protocols that verify certificates on the client end. They have different technical implementations. For example, the way handshakes are performed in SSL vs TLS is drastically different. Unless you're a researcher or highly technical user, chances are that the differences between TLS and SSL will be inconsequential for you.
But how can you ensure you're using the latest versions of TLS and not older SSL protocols?
Even if your certificate is branded as an "SSL certificate," your certificate already supports both SSL and TLS protocols. Therefore, you don't need to change your certificate to use TLS.
Rather, you should control which protocol your website uses at the server level. You can run the SSL Server Test if you need help determining which protocols are currently enabled for your website.
At KeyCDN, we ensure that TLS 1.3 is built into all of our edge servers so our customers can take full advantage of this standard.
TLS 1.2 is still enabled at KeyCDN to ensure that the handshake always works. This is because, for the TLS/SSL handshake to work, both the web server and the client (usually a visitor's web browser) must support the same protocol. Enabling both protocols can increase compatibility.
For example, Internet Explorer and Opera Mini still lack TLS 1.3 support:
Final takeaways
In short, for the average person, there's no practical difference between TLS and SSL. You could enable only one protocol or the other and still be able to browse the vast majority of the web just fine. The way they operate is different, but again, these are highly technical differences. Though they've wavered over the years, they're relatively similar now just like they were in 1999.
The only thing to watch out for is what cipher suites are enabled in both SSL and TLS. Remember the adage that a chain is only as secure as its weakest link! In the case of SSL vs TLS, both are equally vulnerable if you use a poor cipher suite. There's an almost infinite list of outdated suites, and browser updates will usually track which cipher suites are secure and which ones aren't anymore. As a rule of thumb, Google's Chromium-based browsers are usually the first to block unsecured cipher suites.
In a nutshell, TLS and SSL have varied over the years, and TLS formed as a result of SSL. While the term SSL is still dominant, most people actually mean TLS when they talk about SSL because the public versions of SSL have long been deprecated.