TLS & HTTPS

The TLS handshake sets up a secure channel before any HTTP data flows. In it, the client and server agree on the protocol version and cipher suite, the server presents its certificate to prove its identity (the client verifies it against trusted CAs), and they establish a shared session key — typically via an (EC)DHE key exchange — used to symmetrically encrypt the rest of the conversation. The result is the three guarantees of TLS: confidentiality (encryption), integrity (tamper detection), and authentication (you are talking to the real server).

A Certificate Authority is a trusted entity that verifies a domain owner's identity and issues a digitally signed certificate binding the domain name to its public key. Browsers and operating systems ship with a set of trusted root CAs; a server's certificate is trusted if it chains, through intermediate CAs, up to one of those roots. This chain of trust is what lets your browser confirm that example.com's public key is authentic and not an impostor's. Let's Encrypt made CA-issued certificates free and automatable, driving HTTPS adoption.

TLS combines both for the best of each. Asymmetric encryption uses a public/private key pair and is computationally expensive but solves the key-distribution problem — it is used during the handshake to authenticate and securely establish a shared secret. Symmetric encryption uses one shared key and is much faster, so once the handshake derives the session key, all the actual application data is encrypted symmetrically. This hybrid gives you secure key exchange (asymmetric) plus high-throughput bulk encryption (symmetric).

Forward secrecy (also Perfect Forward Secrecy) guarantees that compromising the server's long-term private key in the future does not let an attacker decrypt previously recorded sessions. It is achieved with ephemeral key exchanges (ECDHE/DHE): each session derives a unique key from temporary values that are discarded afterward and never stored. Without forward secrecy (e.g. old RSA key exchange), an attacker who records encrypted traffic today and steals the private key years later could decrypt it all retroactively. PFS is now standard and mandatory in TLS 1.3.

HSTS is a response header (Strict-Transport-Security) that tells the browser: "for the next N seconds, only ever connect to this domain via HTTPS, and refuse any HTTP/insecure connection." This prevents SSL stripping man-in-the-middle attacks, where an attacker downgrades a user's initial http:// request and intercepts traffic before the redirect to HTTPS. With HSTS, the browser upgrades to HTTPS automatically and will not let the user click through a certificate warning. The HSTS preload list bakes this protection into browsers even for the very first visit.