At this point, HTTPS is not just becoming as well known a protocol as its unsecured version HTTP, it’s starting to become much more common, and the little green lock showing next to an HTTPS web address showing that the site is safe and to be trusted is all but taken for granted on the majority of websites that you visit today.
That’s all thanks to the efforts of those who have worked long and hard to make HTTPS ubiquitous. The small electronic document that makes it all possible is the public key certificate which every site owner or admin who wants to implement HTTPS must obtain.
This certificate was once everywhere known as an SSL certificate, but these days you might just as much see it called a TLS certificate, and the protocol which uses it is referred to sometimes as SSL, sometimes as TLS.
So what gives? What’s SSL? What’s TLS? And why the confusion between the two?
What’s a certificate?
Let’s start by taking a small step back to talk about what a cryptographic certificate is in the first place. If you ever used a secret code where you replaced letters with numbers or where you assigned a different letter of the alphabet to each letter and then used a key to code and decode messages, you have experience with cryptography.
Specifically, public key cryptography uses complicated math (that we’ll forego the explanation of for now) to create a shared key between two parties and share it out on the open internet in a way that only the two parties who created it can decode messages sent using the key.
In order for it to work, the shared key itself needs to be cryptographically signed, and a public key certificate is used to sign that key. The function the certificate fulfills, then, is to confirm that the machine starting an encrypted exchange of information is not lying about actually representing a domain name or an organization.
The way these certificates is issued is hierarchical in nature. A small number of “Certificate Authorities” (or CAs as you’ll see them called) issue new certificates. These certificate authorities essentially vouch for the owner of a certificate when they issue the certificate. The way they determine whether the requestor of a certificate is legitimate is by verifying that they have control over the domain name that the certificate is being issued to (how to tell what CA issued a certificate).
There are three methods they use to do that:
- Domain Control Validation (aka DCV) via DNS
This is the most common form of domain control validation. The CA provides the requestor of a certificate with a DNS record they need to add to their DNS zone file. Once the CA verifies that the record has been added, they issue the certificate. - Domain Control Validation via email
The CA sends an email to the email address admin@example.com (where ‘example.com’ would be replaced by the domain name being validated) with a link to use to validate the domain. Once the linked page is visited, the CA issues the certificate. - Domain Control Validation via file
The CA provides a text file (using the .txt extension) that the certificate requestor uploads to the server their domain points to. Then, once they can verify that the text file is present, they issue the certificate.
What this does is establish what’s called a “chain of trust,” that enables everyday internet users to have confidence that sensitive information they enter on websites that use HTTPS will be secure and can’t be intercepted by a third-party with bad intentions. Without this “chain of trust,” e-commerce and private online spaces as we know them would never have been possible.
When you open a browser and go to a website protected with HTTPS, your browser will verify the “chain of trust” established by the certificate covering the domain name in question provided by the website you’re visiting. That’s what enables the first step in establishing an HTTPS connection — the “handshake,” the beginning of an SSL or TLS connection, during which encrypted data can be exchanged freely between two applications (your browser and a website for example) on the internet.
That’s basically how SSL or TLS certificates work. But to understand the difference between SSL and TLS, we need to take a look at the history of SSL and TLS.
How was SSL created?
While the prehistory of SSL extends back into the mid-1980s, the original SSL protocols were developed at Netscape Communications. They called the protocols Secure Sockets Layer (or SSL), a name that refers to the two ends of a particular exchange of information over a network.
The first version of SSL, version 1.0, contained too many security flaws to be released, but in 1995 they released SSL 2.0 and shipped it with their flagship internet browser, Netscape Navigator.
Browser wars
The 1990s saw the first major battle in what are now called the “Browser Wars.” This refers to the intense competition and fight for dominance among the developers of different web browser software. This first round of the Browser Wars featured the market-dominant Netscape Navigator being challenged by Microsoft’s Internet Explorer for dominance.
SSL was a key advantage that Netscape had over Microsoft, but it did have some security flaws nonetheless.
It wasn’t long before Microsoft developed their own security protocol derived from SSL 2.0 that fixed these flaws called Private Communications Technology or PCT to compete with Netscape’s SSL.
Not to be outdone, Netscape completely redesigned SSL and released a new version — SSL 3.0.
The birth of TLS
Having competing, proprietary protocols for internet security would ultimately mean making the internet less secure overall, and would require websites to implement multiple security standards to be compatible with all web browsers.
So, many of the developers who had worked on the original SSL protocol developed a proposal for the Internet Engineering Task Force, the body through which the standard protocols and architecture of the internet are proposed, refined, and published as standards to be universally used and applied.
The proposal essentially consisted of making SSL 3.0 into an internet standard. With some minor changes, they re-branded SSL as Transport Layer Security, or TLS, a reference to the networking ‘layer’ that TLS serves to secure.
In essence, then, TLS is something of a rebranding of SSL. Because of the browser wars, the engineers who worked on it wanted it to be at least superficially distinct from the protocol that was initially developed under the auspices of Netscape, even though TLS 1.0 was essentially SSL 3.1, but one that Microsoft could accept and use for Internet Explorer.
Since then, TLS has been improved several times, and the current version is TLS 1.3. For its part, even though TLS 1.0 came out in 1999, SSL 3.0 was not deprecated until 2015 after in 2014 it was found vulnerable to POODLE attacks (no, nothing to do with dogs).
Which is correct: SSL or TLS?
So technically speaking, TLS is the correct term (and protocol) to use since all versions of SSL are now officially deprecated. But you’ll still hear and see references to SSL certificates, and “SSL certificate” is still a high ranking keyword on search engines.
The main reason is because “SSL” and “SSL Certificate” have come to be much more well known as a term than TLS. And even though SSL is actually no longer used, “SSL” is still used to refer to what is, in actuality, TLS.
So for the question of which term is correct, the technically correct answer is TLS, but culturally speaking, SSL still has relevance.
Tagged in Securityssl
