Since the early days of the web, the SSL protocol and its descendent, TLS, have provided the encryption and security that make modern internet commerce possible. The decades-long history of these protocols has been marked by continuous updates that aim to keep pace with increasingly sophisticated attackers. The next major version of the protocol, TLS 1.3, will soon be finalized — and most anyone who runs a website will want to upgrade, because cybercriminals are catching up.
What is SSL?
Secure Sockets Layer, or SSL, was the original name of the protocol when it was developed in the mid-1990s by Netscape, the company that made the most popular Web browser at the time. SSL 1.0 was never released to the public, and SSL 2.0 had serious flaws. SSL 3.0, released in 1996, was completely revamped, and set the stage for what followed.
What is TLS?
When the next version of the protocol was released in 1999, it was standardized by the Internet Engineering Task Force (IETF) and given a new name: Transport Layer Security, or TLS. As the TLS specification notes, "the differences this protocol and SSL 3.0 are not dramatic." Thus, it's not really a matter of TLS vs. SSL; rather, the two form a continuously updated series of protocols, and are often lumped together as SSL/TLS.
The TLS protocol encrypts internet traffic of all types. The most common is web traffic; you know your browser is connected via TLS if the URL in your address starts with "https," and there's an indicator with a padlock telling you the connection is secure, as in this screenshot from Chrome:
But TLS can be used by other applications as well, including e-mail and usenet.
How TLS works
Encryption is necessary in order to communicate securely over the internet: if your data isn't encrypted, anyone can examine your packets and read confidential information. The safest method of encryption is called asymmetrical cryptography; this requires two cryptographic keys — pieces of information, usually very large numbers — to work properly, one public and one private. The mathematics here are complex, but in essence, you can use the public key to encrypt the data, but need the private key to decrypt it. The two keys are related to each other by some complex mathematical formula that is difficult to reverse-engineer by brute force. Think of the public key as information about the location of a locked mailbox with a slot on the front, and the private key as the key that unlocks the mailbox. Anyone who knows where the mailbox is can put a message in it; but for anyone else to read it, they need the private key.
Because asymmetrical cryptography involves these difficult mathematical problems, it takes a lot of computing resources, so much so that if you used it to encrypt all the information in a communications session, your computer and connection would grind to a halt. TLS gets around this problem by only using asymmetrical cryptography at the very beginning of a communications session to encrypt the conversation the server and client have to agree on a single session key that they'll both use to encrypt their packets from that point forward. Encryption using a shared key is called symmetrical cryptography, and it's much less computationally intensive than asymmetric cryptography. Because that session key was established using asymmetrical cryptography, the communication session as a whole is much more secure than it otherwise would be.
The process by which that sessions key is agreed upon is called a handshake, since it's the moment when the two communicating computers introduce themselves to each other, and it's at the heart of the TLS protocol.
TLS handshake process
The TLS handshake process is quite complex, and there are a number of variations allowed by the protocol. The following steps provide a broad outline that should give you a sense of how it works.
- The client contacts the server and requests a secure connection. The server replies with the list of cipher suites — algorithmic toolkits of creating encrypted connections — that it knows how to use. The client compares this against its own list of supported cipher suites, selects one, and lets the server know that they'll both be using it.
- The server then provides its digital certificate, an electronic document issued by a third-party authority confirming the server's identity. The most important piece of information in the certificate is the server's public cryptographic key. The client confirms the certificate's authenticity.
- Using the server's public key, the client and server establish a session key that both will use for the rest of the session to encrypt communication. There are several techniques for doing this. The client may use the public key to encrypt a random number that's then sent to the server to decrypt, and both parties then use that number to establish the session key. Alternately, the two parties may use what's called a Diffie–Hellman key exchange to establish the session key.
This article at SSL.com has a great diagram outlining each communication step over the course of the TLS handshake process.
As its name implies, the session key is only good for the course of a single, unbroken communications session. If for some reason communications between client and server are cut off — due to a network problem, for instance, or because the client is idle for too long — a new handshake will be required to establish a new session key when communication is re-established.
TLS 1.2 and TLS 1.2 vulnerabilities
TLS 1.2 is the most current defined version of the protocol, and it has been for several years. It established a host of new cryptographic options for communication. However, like some previous versions of the protocol, it also allowed older cryptographic techniques to be used, in order to support older computers. Unfortunately, that opened it up to vulnerabilities, as those older techniques have become more vulnerable as time has passed and computing power has become cheaper.
In particular, TLS 1.2 has become increasingly vulnerable to so-called "man-in-the-middle" attacks, in which a hacker intercepts packets in mid-communication and sends them on after reading or altering them. It's also open to the POODLE, SLOTH, and DROWN attacks. Many of these problems have arisen in the last two years, increasing the sense of urgency for updating the protocol.
TLS 1.3
Fortunately, help is on the way. Version 1.3 of the TLS protocol, currently in draft form but soon to be finalized, plugs a lot of these holes by jettisoning support for legacy encryption systems. There is backwards compatibility in the sense that connections will fall back to TLS 1.2 if one end isn't capable of using the newer encryptions systems on the 1.3 approved list. However, if, for instance, a man-in-the-middle attack tries to force a fallback to 1.2 in order to snoop on packets, that will be detected and the connection dropped.
There are still servers out there that are using versions of TLS even older than 1.2 — some are still using the original SSL protocol. If your sever is one of those, you should upgrade now, and just leap ahead and upgrade to the draft 1.3 spec.
TLS crimeware
One last note on TLS and security: the good guys aren't the only ones who use it! Many cybercriminals use TLS to encrypt command-and-control traffic between their servers and malware installed on their victim's computers. This ends up inverting the usual state of affairs and leaves the victims of cybercrime looking for a way to decrypt traffic. There are a number of techniques for dealing with this kind of encrypted attack, including using network metadata about the encrypted traffic to get a sense of what attackers are doing without actually reading any of it.