TLS

TLS operates between the transport layer (TCP) and the application layer (HTTP, SMTP, etc.). Before any application data flows, TLS performs a handshake: the client sends supported cipher suites, the server presents its certificate (signed by a trusted CA), they negotiate a session key using asymmetric cryptography (ECDH), then switch to fast symmetric encryption (AES-GCM) for the actual data. The certificate binds a domain name to a public key, proving the server is who it claims to be. Every byte of application data is then encrypted and authenticated with a MAC.

TLS 1.2 vs TLS 1.3

TLS 1.3, published as RFC 8446 in 2018, is a significant redesign rather than an incremental update. The most visible improvement is the handshake: TLS 1.2 requires two full round trips before the client can send application data; TLS 1.3 requires only one. On a connection with 50 ms RTT, that saves 50 ms of setup latency on every new connection — meaningful for page loads that open dozens of connections. TLS 1.3 also introduced mandatory 0-RTT session resumption, which allows a returning client to send application data in the very first packet, eliminating handshake overhead entirely for recently visited servers (with a caveat: 0-RTT data has no replay protection, so servers must handle it carefully). Forward secrecy is mandatory in TLS 1.3 — the RSA key exchange mode was removed, along with CBC-mode ciphers, MD5, SHA-1, and all export-grade algorithms. Only AEAD ciphers remain: AES-128-GCM, AES-256-GCM, and ChaCha20-Poly1305.

TLS handshake walkthrough

The TLS 1.3 handshake works as follows. The client sends a ClientHello containing the TLS version it supports, a list of acceptable cipher suites, and its ECDHE key share (a Diffie-Hellman public value). The server responds with a ServerHello that selects a cipher suite and includes its own key share, then immediately appends its Certificate (the X.509 cert chain) and a CertificateVerify signature proving it holds the corresponding private key, followed by a Finished message. At this point both sides can derive identical symmetric session keys from the key exchange. The client verifies the certificate chain and sends its own Finished. Application data begins flowing — all within one round trip. TLS 1.2 separated cipher negotiation and key exchange into two distinct round trips, which is why it requires twice as many RTTs.

Certificate validation

A TLS certificate is validated through a chain of trust. The server presents its end-entity certificate, which was signed by an intermediate CA, which was signed by a root CA. The client checks that the root CA is in its trusted store (browsers and operating systems ship with ~100–150 trusted roots). Additional checks: the certificate's validity period must encompass today's date, the server's hostname must match the Subject Alternative Name (SAN) field in the certificate (Common Name alone is no longer sufficient per RFC 2818), and the certificate must not be revoked. Revocation is checked via OCSP (Online Certificate Status Protocol) — the client queries the CA's OCSP responder to confirm the certificate has not been invalidated before its expiry date.

Cipher suite components

A TLS cipher suite names the algorithms used for each cryptographic function. In TLS 1.3, suite names like TLS_AES_256_GCM_SHA384 specify: AES-256-GCM for authenticated symmetric encryption of bulk data, and SHA-384 for the HKDF key derivation function. The key exchange algorithm (ECDHE) is negotiated separately and not part of the suite name in TLS 1.3. In TLS 1.2, the full suite name included all four components — for example TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 — specifying ECDHE for key exchange, RSA for server authentication, AES-256-GCM for encryption, and SHA-384 for the MAC.

Perfect forward secrecy

Perfect forward secrecy (PFS) means that the session keys used to encrypt a connection cannot be derived from the server's long-term private key. In practice, this is achieved by using ephemeral Diffie-Hellman key pairs (ECDHE) — the server generates a fresh key pair for every connection, and that key pair is discarded after the session. If an attacker records encrypted traffic today and later compromises the server's private key, they still cannot decrypt those past sessions because the ephemeral session keys are gone. TLS 1.2 without PFS used RSA key exchange, where the pre-master secret was directly encrypted with the server's long-term RSA key — recording traffic and later obtaining the private key was enough to decrypt everything. TLS 1.3 made forward secrecy mandatory by removing RSA key exchange entirely.

TLS inspection by corporate firewalls

Many enterprise firewalls perform TLS inspection (also called SSL inspection or MITM decryption). The firewall acts as a man-in-the-middle: it terminates the client's TLS connection, decrypts the traffic, inspects it for malware or policy violations, re-encrypts it with a certificate signed by an enterprise CA, and forwards it to the destination. The enterprise CA's root certificate is pre-installed on corporate devices via group policy, which is why browsers do not show a warning. From the client's perspective, the connection appears legitimate. Privacy implications are significant: the firewall sees all HTTPS traffic, including credentials entered on external sites. Employees on corporate devices should assume encrypted traffic to any destination is visible to the IT security team.

Common TLS errors and causes

• ERR_CERT_DATE_INVALID: Certificate expired or system clock is wrong.
• ERR_CERT_COMMON_NAME_INVALID: Hostname does not match the SAN field in the certificate.
• ERR_CERT_AUTHORITY_INVALID: Certificate not signed by a trusted root — self-signed or chain incomplete.
• SSL_ERROR_HANDSHAKE_FAILURE_ALERT: No common cipher suite or TLS version between client and server.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH: Server configured for TLS versions or ciphers the client does not support.

Frequently Asked Questions

What is the difference between TLS and SSL?

SSL is the deprecated predecessor. TLS 1.0 replaced SSL 3.0 in 1999; TLS 1.2 and 1.3 are the only versions in use today. The term "SSL certificate" is a legacy misnomer — modern certificates are TLS certificates. SSL 2.0, 3.0, and TLS 1.0/1.1 are all deprecated due to known vulnerabilities.

What is the difference between TLS 1.2 and TLS 1.3?

TLS 1.3 is faster (1 vs 2 handshake RTTs, 0-RTT resumption) and more secure (only AEAD ciphers, mandatory forward secrecy, no weak algorithms). Browsers prefer TLS 1.3 when both sides support it. TLS 1.2 still works with modern cipher suites but is slower and supports legacy weak options.

Does TLS affect connection speed?

Minimally. TLS 1.2 adds ~1–2 RTTs of handshake latency; TLS 1.3 adds ~1 RTT. On modern hardware with AES-NI, encryption overhead is negligible. Session resumption eliminates most handshake cost for returning connections. Security benefit far outweighs the minor latency cost.