TLS: Transport Layer Security

What is TLS?

TLS (Transport Layer Security) is a cryptographic protocol designed to provide secure communication over a computer network. It delivers three fundamental security properties: encryption (preventing eavesdropping), authentication (verifying the identity of communicating parties), and integrity (detecting any tampering with transmitted data).

TLS is the successor to SSL (Secure Sockets Layer), which was originally developed by Netscape in the mid-1990s. When the IETF (Internet Engineering Task Force) took over development, they renamed the protocol to TLS. The current version, TLS 1.3, was published in 2018 as RFC 8446. It represents a significant overhaul that removed legacy cryptographic algorithms and streamlined the handshake process.

In the network stack, TLS sits between the application layer and the transport layer. It does not operate on a specific port. Instead, it wraps protocols like HTTP, SMTP, and IMAP, adding encryption transparently. When HTTP runs over TLS, the combination is called HTTPS. When SMTP runs over TLS, it is called SMTPS or uses the STARTTLS upgrade mechanism. This flexibility is what makes TLS the most widely deployed security protocol on the internet.

Nearly every secure connection you make online relies on TLS. Web browsing, email, VPN tunnels, API calls, database connections, and instant messaging all depend on TLS to keep data confidential and tamper-proof.

The TLS 1.3 Handshake

Before encrypted communication can begin, the client and server must agree on cryptographic parameters and establish shared secret keys. This negotiation process is called the TLS handshake. TLS 1.3 dramatically improved the handshake by reducing it to a single round trip (1-RTT), down from two round trips in TLS 1.2.

1-RTT Handshake Flow

The client sends a ClientHellomessage containing the list of supported cipher suites and one or more key shares (the client's half of the key exchange). By including key shares speculatively, TLS 1.3 saves an entire round trip compared to earlier versions.

The server responds with a ServerHellothat includes the selected cipher suite, the server's key share, its X.509 certificate, and a CertificateVerify message proving possession of the private key. With TLS 1.3, this entire response is already encrypted using keys derived from the key exchange.

The client verifies the server's certificate, confirms the CertificateVerify signature, and sends a Finished message. At this point, both sides have derived identical session keys and all subsequent data is fully encrypted.

0-RTT Resumption

For returning clients, TLS 1.3 supports 0-RTT (zero round trip time) resumption. If a client has connected to a server before and cached a pre-shared key (PSK), it can send encrypted application data in its very first message, alongside the ClientHello. This eliminates the handshake latency entirely for repeat visits.

However, 0-RTT data comes with an important caveat: it is vulnerable to replay attacks. An attacker who captures the initial message can resend it, potentially causing the server to process the same request twice. For this reason, servers should only accept 0-RTT data for idempotent operations (like GET requests) and never for state-changing actions.

TLS Record Protocol

Once the handshake is complete, the TLS record protocol handles the actual transmission of encrypted data. It takes application data and processes it through several steps before sending it over the network.

Record Processing Pipeline

The record protocol breaks application data into manageable fragments, each with a maximum size of 16,384 bytes (2^14). In older TLS versions, the data could optionally be compressed, but compression is now disabled by default due to attacks like CRIME. Next, the record is authenticated and encrypted using the negotiated AEAD cipher (for example, AES-128-GCM). Finally, a 5-byte record header is prepended, specifying the content type, protocol version, and fragment length.

Record Content Types

Each TLS record has a content type field that identifies the kind of data it carries:

• Handshake (22): messages used during the TLS handshake, such as ClientHello and ServerHello
• Application Data (23): the actual encrypted payload from the application layer
• Alert (21): error and warning messages, including fatal alerts that terminate the connection
• ChangeCipherSpec (20): a legacy record type retained for compatibility with middleboxes, though it serves no cryptographic purpose in TLS 1.3

In TLS 1.3, the actual content type is hidden inside the encrypted payload. The outer record header always claims the type is Application Data (23), preventing observers from distinguishing handshake messages from application traffic.

TLS Cipher Suites

A cipher suite defines the set of cryptographic algorithms used for a TLS connection. TLS 1.3 simplified cipher suites dramatically compared to TLS 1.2, which had over 300 possible combinations. TLS 1.3 defines only five cipher suites, and three of them account for virtually all real-world usage.

TLS 1.3 made several important changes to cipher suite selection. All non-AEAD ciphers were removed, meaning every cipher in TLS 1.3 provides both encryption and authentication in a single operation. Static RSA key exchange was eliminated entirely, so all connections use ephemeral key exchange (ECDHE or DHE) and benefit from forward secrecy. CBC mode ciphers, which were the source of numerous attacks (BEAST, Lucky Thirteen, POODLE), were also dropped.

AES-GCM is the most common choice on hardware that supports AES-NI instructions (most modern x86 processors). ChaCha20-Poly1305 is preferred on devices without hardware AES acceleration, such as older mobile phones, because it delivers strong performance in software.

SSL/TLS Version History

The evolution of SSL and TLS spans over two decades, with each version addressing vulnerabilities discovered in its predecessors. Understanding this history explains why modern configurations should use TLS 1.2 or 1.3 exclusively.

SSL 2.0 (1995)

The first publicly released version of SSL. It was fundamentally broken in several ways, including weak MAC construction, the ability to force weaker cipher suites via downgrade attacks, and a lack of protection for the handshake. SSL 2.0 should never be used.

SSL 3.0 (1996)

A complete redesign that addressed the core flaws of SSL 2.0. It served as the foundation for TLS and was widely used for nearly two decades. SSL 3.0 was formally deprecated in 2015 (RFC 7568) after the POODLE attack (2014) demonstrated that its CBC mode padding could be exploited to decrypt data.

TLS 1.0 (1999)

Published as RFC 2246, TLS 1.0 was essentially SSL 3.0 with minor improvements to the MAC calculation and alert handling. While more secure than SSL, it still used CBC mode without explicit IVs, making it vulnerable to the BEAST attack. TLS 1.0 was deprecated in 2020.

TLS 1.1 (2006)

TLS 1.1 (RFC 4346) fixed the implicit IV vulnerability by introducing explicit initialization vectors for CBC ciphers. Despite this fix, it saw limited adoption because TLS 1.2 was released just two years later. TLS 1.1 was deprecated alongside TLS 1.0 in 2020.

TLS 1.2 (2008)

Published as RFC 5246, TLS 1.2 introduced AEAD cipher support (AES-GCM), replaced MD5/SHA-1 with SHA-256 in the PRF (pseudorandom function), and added flexibility in signature algorithms. TLS 1.2 remains widely deployed and is considered secure when configured with modern cipher suites. Most servers today support both TLS 1.2 and 1.3.

TLS 1.3 (2018)

The latest version (RFC 8446) was a major overhaul. TLS 1.3 removed all legacy algorithms, reduced the handshake to 1-RTT, mandated AEAD encryption, eliminated static RSA key exchange, and added 0-RTT resumption. It encrypts more of the handshake to resist traffic analysis and provides forward secrecy by default.

Certificate Validation in TLS

During the TLS handshake, the server presents an X.509 digital certificate to prove its identity. The client must validate this certificate before trusting the connection. Certificate validation involves several checks:

• Chain of trust:the client verifies that the server's certificate was signed by a trusted Certificate Authority (CA). The chain typically goes from a root CA to one or more intermediate CAs to the server's leaf certificate. Browsers and operating systems ship with a pre-installed set of trusted root CAs.
• Domain name match:the certificate's Subject Alternative Name (SAN) field must match the hostname the client is connecting to. Wildcard certificates (e.g., *.example.com) can cover multiple subdomains.
• Expiration check:the certificate must be within its validity period (not before the "Not Before" date and not after the "Not After" date). Most certificates are valid for 90 days (Let's Encrypt) to one year.
• Revocation check: the client checks whether the certificate has been revoked by the CA using CRL (Certificate Revocation Lists) or OCSP (Online Certificate Status Protocol). OCSP stapling, where the server includes a fresh OCSP response during the handshake, avoids the need for the client to contact the CA directly.

Let's Encrypt, launched in 2016, transformed the certificate landscape by offering free, automated certificates. It is now the largest CA on the internet by certificate volume. Certificate Transparency (CT) logs provide a public, append-only record of all issued certificates, allowing domain owners to detect unauthorized certificate issuance.

TLS and Forward Secrecy

Perfect forward secrecy (PFS) is a property that ensures past communication sessions remain secure even if the server's long-term private key is compromised in the future. With PFS, an attacker who records encrypted traffic and later obtains the private key still cannot decrypt the captured sessions.

PFS works because each connection uses ephemeral (temporary) keys for the actual encryption. The server's private key is only used to authenticate during the handshake, not to derive the encryption keys directly. Once the session ends, the ephemeral keys are discarded, and there is no way to reconstruct them from the long-term key.

TLS 1.3 mandates forward secrecy for all connections. Every handshake must use an ephemeral Diffie-Hellman key exchange (ECDHE or DHE). In TLS 1.2, forward secrecy depends on the cipher suite chosen. Suites using static RSA key exchange (like TLS_RSA_WITH_AES_128_CBC_SHA) do not provide PFS, while those using ECDHE (like TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) do. This is one of the main reasons TLS 1.3 removed static RSA key exchange entirely.

Common Use Cases for TLS

• HTTPS (web browsing): HTTP over TLS on port 443, securing virtually all modern web traffic
• SMTPS / STARTTLS (email sending): encrypting email transmission between clients and mail servers
• IMAPS (email retrieval): IMAP over TLS on port 993 for secure mailbox access
• LDAPS (directory services): LDAP over TLS on port 636, used in enterprise identity management
• FTPS (file transfer): FTP with TLS encryption for secure file uploads and downloads
• Database connections: PostgreSQL, MySQL, and other databases support TLS to encrypt data in transit between application servers and database servers
• gRPC:Google's RPC framework uses TLS by default for all communication between services
• MQTT with TLS: IoT messaging protocol secured with TLS on port 8883

Frequently Asked Questions About TLS

What is the difference between TLS and SSL?

TLS is the successor to SSL. SSL was developed by Netscape (versions 2.0 and 3.0), while TLS is maintained by the IETF. TLS 1.0 was essentially SSL 3.1 with a name change. All SSL versions are now deprecated and considered insecure. When people say "SSL" today, they almost always mean TLS. The term "SSL certificate" is a common misnomer, as all modern certificates use TLS.

Is TLS 1.2 still secure?

Yes, TLS 1.2 is still considered secure when configured properly. The key is to use only AEAD cipher suites (AES-GCM or ChaCha20-Poly1305) with ECDHE key exchange. Avoid CBC mode ciphers and static RSA key exchange. That said, TLS 1.3 is preferred because it removes the possibility of misconfiguration by only supporting secure options.

What is AEAD and why does TLS 1.3 require it?

AEAD stands for Authenticated Encryption with Associated Data. It combines encryption and authentication into a single operation, which eliminates an entire class of attacks that exploited the separate encrypt-then-MAC construction used in older TLS versions. AES-GCM and ChaCha20-Poly1305 are both AEAD ciphers. By mandating AEAD, TLS 1.3 ensures that every implementation is protected against padding oracle attacks, timing attacks on MAC verification, and related vulnerabilities.

What is 0-RTT in TLS 1.3?

0-RTT (zero round trip time) is a TLS 1.3 feature that allows returning clients to send encrypted data immediately, without waiting for the handshake to complete. It uses a pre-shared key from a previous session. While this eliminates connection latency, 0-RTT data can be replayed by an attacker. Servers must ensure that 0-RTT requests are idempotent (safe to repeat) or implement replay protection mechanisms.

How do I check which TLS version a site uses?

In most browsers, click the lock icon in the address bar and look at the connection details. You can also use command-line tools like openssl s_client -connect example.com:443to see the negotiated TLS version, cipher suite, and certificate details. Online tools like SSL Labs' SSL Server Test provide a comprehensive analysis of a server's TLS configuration.

What is the difference between TLS and HTTPS?

TLS is a general-purpose encryption protocol. HTTPS is specifically HTTP running over TLS. TLS can secure many protocols (SMTP, IMAP, FTP, MQTT, and more), while HTTPS refers only to web traffic. In other words, HTTPS is one application of TLS, not the other way around.

Related Protocols

• SSL: the predecessor to TLS, now deprecated but historically significant
• HTTPS: HTTP secured with TLS, the standard for web browsing
• HTTP: the application layer protocol that TLS encrypts for web traffic
• TCP: the transport layer protocol that TLS runs on top of
• SSH: another security protocol for remote access, with its own encryption layer