TLS and HTTPS

Every time your browser shows a little padlock, an extraordinary piece of cryptographic choreography has just happened — in well under a tenth of a second, over a network run by strangers, with an adversary potentially reading every byte. Two computers that have never met, sharing no secret in advance, have agreed on a key that only they know, verified that the server really is the bank it claims to be, and switched on encryption for everything that follows. The protocol that pulls this off is TLS — Transport Layer Security — and HTTPS is just HTTP running inside a TLS tunnel.

This page is about what TLS actually promises, where it sits in the stack, and — the heart of it — the step-by-step handshake by which two strangers bootstrap a private, authenticated channel. We will focus on TLS 1.3 (the current version, 2018), which is both simpler and faster than everything before it.

What TLS adds, and where it sits

A raw TCP connection is a bare byte pipe: anyone who can see the wire can read it, change it, or impersonate either end. TLS wraps that pipe and adds three guarantees — the trio worth memorising:

Confidentiality — the data is encrypted, so an eavesdropper on the path sees only ciphertext. (Provided by symmetric encryption once a shared key exists.)
Integrity — the data is tamper-evident: any modification in transit is detected and the connection is torn down. (Provided by authenticated encryption / a MAC.)
Authentication — you can be sure who is on the other end (at least the server; optionally the client too), so you are not talking to an impostor. (Provided by certificates and digital signatures.)

In the layer stack, TLS slots in between TCP and the application. TCP delivers an ordered, reliable byte stream; TLS sits on top of that stream and encrypts it; the application (HTTP, SMTP, IMAP, …) runs on top of TLS, blissfully unaware. When HTTP runs over this TLS layer, we call it HTTPS, and it lives on port 443 instead of HTTP's port 80. Nothing about HTTP itself changes — the same GETs and POSTs flow — they just travel inside the encrypted tunnel.

Layer	Role
Application (HTTP)	Requests and responses — unaware it is protected
TLS	Encrypts, authenticates, integrity-protects the byte stream
TCP	Reliable, ordered byte delivery
IP	Best-effort packet routing

Why hybrid crypto: asymmetric to agree, symmetric to bulk

You already know two kinds of encryption: symmetric and asymmetric. TLS uses both, and the reason is the whole trick of practical cryptography.

Symmetric encryption (e.g. AES) is fast — it can encrypt gigabytes per second — but it needs both sides to already share the same secret key. Over a public network, how do two strangers agree on a secret key without an eavesdropper learning it?
Asymmetric encryption and key exchange (e.g. Diffie–Hellman, RSA) solve exactly that bootstrapping problem — two parties can agree a shared secret in the open — but it is slow, far too slow to encrypt a whole video stream with.

So TLS does the sensible thing: use the slow asymmetric maths once, at the start, only to agree a symmetric key; then use the fast symmetric cipher for all the actual data. This is hybrid encryption, and it is the pattern behind essentially every secure channel on the Internet. The handshake's entire job is to get both ends holding the same symmetric key, with confidence in who they are talking to — after that, bulk data flies under cheap symmetric encryption.

The TLS 1.3 handshake, step by step

Here is the choreography. In TLS 1.3 it fits in a single round trip (1-RTT): the client speaks, the server answers, and by the time the client sends its first real request the channel is already secure. Follow the timeline.

ClientHello. The client opens with the list of cipher suites it supports and — the key TLS 1.3 speed-up — an ephemeral Diffie–Hellman key share (g^x) already included. It is guessing the server will accept it, so no extra round trip is wasted negotiating.
ServerHello. The server picks a cipher suite and sends back its own ephemeral DH share (g^y). Now both sides can independently compute the same shared secret g^{xy} — this is the key agreement, and crucially an eavesdropper who saw g^x and g^y cannot compute g^{xy}.
Certificate. The server sends its certificate chain — a document binding "bank.com" to a public key, signed by a Certificate Authority (next section).
CertificateVerify. The server signs a hash of the whole handshake so far with the private key matching its certificate. This proves it actually owns the private key, not just a copy of someone's certificate — you cannot replay a stolen certificate without the key.
Finished. Each side sends a MAC over the entire handshake transcript, so both can confirm nothing was tampered with along the way. The client checks the certificate and signature; if anything fails, it aborts. Otherwise, application data now flows, symmetrically encrypted, in both directions.

Note the elegant division of labour: Diffie–Hellman gives the shared secret, the certificate + signature give the identity, and the two are independent — which is exactly what makes forward secrecy (below) possible.

Certificates and the chain of trust

The handshake proves the server owns a private key. But how do you know that key belongs to bank.com and not an attacker who generated a key and claims to be bank.com? That is the job of a certificate and the Certificate Authority (CA) system.

A certificate is a small signed document saying "the public key K belongs to bank.com," stamped with the digital signature of a Certificate Authority. Your browser (or operating system) ships with a built-in list of a few dozen trusted root CAs. The trust flows in a chain:

A root CA (whose certificate is baked into your browser) signs an intermediate CA's certificate.
The intermediate CA signs bank.com's certificate.
Your browser walks the chain: bank.com ← intermediate ← root, checking each signature, until it reaches a root it already trusts.

If every signature in the chain checks out and terminates at a trusted root, the certificate is accepted. If any link fails — an unknown issuer, an expired certificate, a name that doesn't match the site — the browser throws the big red warning. This is a public-key infrastructure (PKI): trust in millions of servers reduced to trust in a handful of roots.

The single most dangerous misconception about HTTPS: people read the padlock as "this site is safe / legitimate / not a scam." It means no such thing. All the padlock certifies is that the connection is encrypted and that you are really talking to whoever owns the domain name in the address bar — and that anyone can get a valid certificate for a domain they control, including criminals, in minutes, for free.

A phishing site at secure-paypa1-login.com can have a perfectly valid certificate and a gleaming padlock. The padlock confirms you have a private, tamper-proof line to that server — it says nothing about whether the server is honest, the company reputable, or the page not a scam. In fact the majority of phishing sites now use HTTPS precisely because users have been taught "padlock = safe." The correct reading is: the padlock protects the channel, not you from the site. Always check the actual domain name, not the lock. See phishing and social engineering.

Forward secrecy: the reason for ephemeral keys

Look again at the handshake: the shared key came from ephemeral Diffie–Hellman — fresh random values x and y generated for this one session and thrown away afterwards. That word "ephemeral" buys a powerful property: forward secrecy.

Each session's key is derived from throwaway values, not from the server's long-term private key. So even if the server's private key is stolen later, an attacker who recorded past encrypted traffic still cannot decrypt it — the ephemeral secrets that protected those sessions are long gone.

This defeats the "store now, decrypt later" attack: a well-resourced adversary who quietly records everything today, hoping to steal the key next year, gets nothing but noise, because the keys that mattered never existed on disk and were destroyed the moment each session ended. Forward secrecy is why TLS 1.3 mandates ephemeral key exchange for every connection.

What changed in TLS 1.3

TLS 1.3 was a deliberate simplification and hardening of the sprawling 1.2 protocol. The headline changes:

One round trip (1-RTT), not two. By putting a key share in the very first message (ClientHello), the client and server reach a secure channel in a single round trip — TLS 1.2 needed two, adding a whole RTT of latency to every new connection. (There is even an optional 0-RTT resumption mode for repeat visits.)
RSA key transport dropped. Old TLS could encrypt the session key to the server's RSA public key — which meant no forward secrecy (steal the key, decrypt all past sessions). TLS 1.3 removed that option entirely: every handshake uses ephemeral Diffie–Hellman, so forward secrecy is not optional, it is guaranteed.
The old ciphers are gone. Decades of accumulated weak and broken options (RC4, 3DES, MD5, static RSA, insecure renegotiation) were pruned. TLS 1.3 offers only a small set of strong, modern authenticated-encryption suites — fewer footguns, fewer downgrade attacks.
More of the handshake is encrypted. Even the server's certificate is now sent encrypted, leaking less metadata to eavesdroppers.

In the old RSA-key-transport mode, the client picked the session secret and sent it encrypted with the server's long-term RSA public key. The only way to decrypt that — ever — is the server's long-term private key. So an adversary who records the traffic today and steals that one private key years later can decrypt every recorded session that ever used it. There is a single point of catastrophic failure that reaches backward in time.

Ephemeral Diffie–Hellman severs that link. The session secret is never transmitted at all — each side contributes a throwaway value and they derive the shared key independently, then discard the throwaway values. The long-term private key is used only to sign (prove identity), never to encrypt the session key. Stealing it later lets you impersonate the server going forward, but it unlocks none of the recorded past. Forward secrecy falls out automatically — which is exactly why TLS 1.3 made ephemeral DH the only option.