SSL and TLS

SSL: Secure Sockets Layer
TLS: Transport Layer Security

SSL and TLS are cryptographic communication protocols which provide privacy and guarantee data integrity. They create a secure channel over an otherwise insecure network.

SSL was developed by Netscape in 1996 as a way to encrypt web traffic. It was popular in the early internet, especially for e-commerce and online payments. However, SSL suffers from a few security vulnerabilities which have caused it to be deprecated—meaning it is going away soon and being used less and less.

TLS was created by the Internet Engineering Task Force in 1999 as a replacement for SSL. TLS is currently considered secure and is widely used in a variety of online communications: websites, file transfers, email, instant messaging, voice-over-IP (VoIP).

It is ironic that TLS is a replacement for SSL, and has never been compatible with SSL, yet most people commonly refer to TLS as “SSL”. When you hear anyone say “SSL”, think “TLS”.

TLS has three main advantages:

Confidentiality: No one can eavesdrop on the encrypted data.
Data integrity: No one can modify signed data.
Identity integrity: No one can fake their identity.

TLS Versions

Not all TLS versions are equally secure. TLS 1.0 (1999) and TLS 1.1 were officially deprecated by the IETF in 2021 (RFC 8996) due to reliance on weak cryptographic primitives including SHA-1. Modern deployments should use TLS 1.2 as the minimum supported version, and TLS 1.3 (published as RFC 8446 in 2018) is the currently preferred standard. SSL 3.0 and earlier, as well as TLS 1.0 and 1.1, should be disabled on all servers.

TLS Handshake and Communication

A TLS connection between a client and server begins when the client contacts the server and indicates a desire to use TLS for communication. The client and server then initiate a handshake procedure, basically a negotiation about the configuration options that the two will use to communicate. The most important of these configurations is which encryption algorithms will be used. This depends on the algorithms the client and server support, allow, and prefer.

In TLS 1.3 (RFC 8446, §2) the two sides use ephemeral Diffie-Hellman — either finite-field DHE or elliptic-curve ECDHE — to derive a shared session secret. Neither side ever encrypts a session key with the server’s long-term RSA key; the static-RSA and static Diffie-Hellman cipher suites that earlier TLS versions supported have been removed. The server still proves its identity by signing the handshake transcript with the private key that matches its certificate, so Public-Key Cryptography is used for authentication, while the ephemeral (EC)DH exchange is what establishes the encryption keys. Because the long-term key is never used to wrap a session key, every TLS 1.3 connection provides forward secrecy as a property of the protocol.

Once the shared session secret is established, the client and server switch to Symmetric Key Algorithms (AEAD ciphers such as AES-GCM or ChaCha20-Poly1305) for the bulk of the conversation. These algorithms are much faster than public-key cryptography. Each message sent in either direction is encrypted and authenticated under the symmetric keys derived during the handshake.

Besides providing privacy, TLS provides important prevention measures against a number of attacks, including credential theft, cookie theft, and session hijacking. The main disadvantage is that it is slower simply because all data must be encrypted before sending and decrypted once it is received. This was a significant barrier to adoption ten years ago, however it is only a small issue for much faster, modern computers. It remains a concern for less-powerful mobile devices and for sites which need to serve up large files, such as online video. The cost and setup are minimal, but do keep it from being more widely adopted.

Heartbleed Bug

The Heartbleed bug was a major vulnerability discovered in the OpenSSL library in 2014. It was a significant concern because the OpenSSL library is widely used for TLS. It has been estimated that at least 20% of secure servers use OpenSSL.

The bug allowed an attacker to read parts of server memory which they should not be able to see (technically called a “buffer over-read”). It had the potential to compromise a server’s private keys, and once an attacker has the private keys, it compromises all TLS communications with that server.

A media campaign was organized (including a catchy name, logo, and website) to make as many developers aware of the issue and to get as many servers upgraded with a patched version of OpenSSL as quickly as possible.

Unfortunate cases like Heartbleed, provide an example of why forward secrecy is important. TLS can guarantee forward secrecy if configured correctly.