What is TLS?

Transport Layer Security (TLS) is the protocol that puts the "S" in HTTPS. Every time you see that padlock icon in your browser, TLS is working behind the scenes to encrypt the connection between your browser and the server.

Without TLS, everything you send over the internet — passwords, credit card numbers, private messages — travels as plaintext. Anyone on the same network could read it. TLS solves this by encrypting the data in transit and verifying the identity of the server you're talking to.

A Brief History

TLS evolved from SSL (Secure Sockets Layer), which was developed by Netscape in the mid-1990s:

SSL 2.0 (1995) — First public release. Had serious security flaws.
SSL 3.0 (1996) — Complete redesign. Better, but still vulnerable (see: POODLE attack).
TLS 1.0 (1999) — Successor to SSL 3.0, standardized by the IETF. Minor changes from SSL 3.0.
TLS 1.2 (2008) — Added support for modern ciphers like AES-GCM. Still widely used today.
TLS 1.3 (2018) — Major overhaul. Faster handshakes, removed legacy algorithms, better security defaults.

When people say "SSL" today, they almost always mean TLS. The SSL protocol itself has been deprecated for years.

The TLS Handshake

Before any encrypted data flows, the client and server must agree on how to encrypt. This negotiation is called the TLS handshake. Here's how it works in TLS 1.3:

1. Client Hello

The client sends a message containing:

Supported TLS versions
Supported cipher suites (encryption algorithms)
A random number (client random)
Key share — the client's contribution to the key exchange

In TLS 1.3, the client optimistically includes key share data in the first message, which is why the handshake is faster than TLS 1.2.

2. Server Hello

The server responds with:

The chosen TLS version
The selected cipher suite
A random number (server random)
The server's key share
The server's certificate (proving its identity)
A certificate verification signature

3. Key Derivation

Both sides now have everything they need to derive the session keys — symmetric encryption keys used for the actual data transfer. This uses a key exchange algorithm like X25519 or P-256.

The critical insight: the key exchange happens using asymmetric cryptography (public/private key pairs), but the actual data encryption uses symmetric cryptography (shared secret keys). Asymmetric crypto is secure but slow. Symmetric crypto is fast. The handshake uses the slow method once to establish a shared secret, then everything after that uses the fast method.

4. Encrypted Communication

With session keys established, all subsequent data is encrypted using an AEAD cipher like AES-256-GCM or ChaCha20-Poly1305. These ciphers provide both confidentiality (nobody can read the data) and integrity (nobody can tamper with it without detection).

Certificates and Trust

How does your browser know it's actually talking to google.com and not an attacker? That's where certificates come in.

A TLS certificate contains:

The domain name it's valid for
The server's public key
The certificate authority (CA) that issued it
An expiration date
A digital signature from the CA

Your browser maintains a list of trusted Certificate Authorities. When a server presents its certificate, the browser verifies the CA's signature against its trusted list. If the signature checks out, the browser trusts that the certificate — and therefore the server — is legitimate.

This creates a chain of trust: you trust the CA, the CA vouches for the server, therefore you trust the server.

Certificate Transparency

How do you prevent a rogue CA from issuing fraudulent certificates? Certificate Transparency (CT) logs. Every publicly trusted certificate must be logged in public, append-only CT logs. Browsers check these logs to detect misissued certificates.

Perfect Forward Secrecy

TLS 1.3 mandates Perfect Forward Secrecy (PFS). This means that even if a server's private key is compromised in the future, past recorded traffic cannot be decrypted.

This works because TLS 1.3 uses ephemeral key exchange. Each connection generates fresh key pairs that are discarded after the session ends. There's no long-lived secret that could be extracted later to unlock old sessions.

Compare this to older RSA key exchange (removed in TLS 1.3), where the same server private key was used for every connection. If that key leaked, every past session could be decrypted.

Common Misunderstandings

"TLS encrypts everything." — TLS encrypts the content of the connection, but metadata like the destination IP and (in TLS 1.2) the SNI hostname are visible to network observers. TLS 1.3 introduced Encrypted Client Hello (ECH) to address the SNI leak.

"HTTPS means the site is safe." — HTTPS means the connection is encrypted. It doesn't mean the server itself isn't malicious. Phishing sites can and do use HTTPS.

"TLS adds significant latency." — In TLS 1.3, the handshake completes in just one round trip (1-RTT). With session resumption (0-RTT), reconnecting to a previously visited server adds zero additional round trips.

Why This Matters for Engineers

Understanding TLS is essential for:

Debugging production issues: Certificate expiration, cipher suite mismatches, and TLS version incompatibilities cause real outages
Security architecture: Deciding where to terminate TLS (at the load balancer? at each service?), implementing mutual TLS for service-to-service auth
Performance optimization: Choosing between RSA and ECDSA certificates, enabling OCSP stapling, configuring session tickets
Compliance: Many regulations (PCI DSS, HIPAA, SOC 2) require TLS for data in transit

In upcoming lessons, we'll dig deeper into specific topics like mutual TLS, certificate management at scale, and the mathematics behind the cryptographic primitives.