TLS: How Your Browser Knows It's Talking to the Right Server
TLS combines everything from this course — hashing, symmetric encryption, public-key cryptography, and key exchange — into the protocol that secures the web. Here's how it fits together.
Every HTTPS connection starts with a TLS handshake. It happens in under 100ms and most developers take it entirely for granted. Underneath that 100ms is a sequence of operations that touch almost every concept in this course.
What the TLS handshake does
It accomplishes three things, in order:
- Authentication: prove the server is who it claims to be.
- Key exchange: derive a shared secret without transmitting it.
- Cipher negotiation: agree on which algorithms to use for the session.
After the handshake, all traffic is encrypted with AES-GCM (or ChaCha20-Poly1305) using the derived session key. The handshake is the expensive part; symmetric encryption is fast.
Certificates and the chain of trust
The server presents a certificate — a document containing its domain name, public key, and a signature from a Certificate Authority (CA). Your browser ships with a list of ~150 trusted root CAs (Mozilla's, Apple's, Microsoft's lists). If the server's certificate is signed by one of those roots (or by an intermediate CA that chains back to a root), your browser trusts it.
The certificate signature is exactly what we covered in Lesson 5: a hash of the certificate contents, signed with the CA's private key. Your browser verifies the signature with the CA's public key. If it's valid, the certificate hasn't been tampered with and was issued by a trusted authority.
This is what the padlock means: not that the connection is private, but that the server's identity has been verified by a CA your browser trusts.
The TLS 1.3 handshake (simplified)
Client sends: "ClientHello" — supported cipher suites, TLS version, and a random nonce. Also sends ECDHE key share so the handshake can be shorter.
Server responds: "ServerHello" — chosen cipher suite, its own ECDHE key share, and its certificate. Both parties can now independently derive the same session key using ECDHE.
Server sends: handshake data encrypted with the derived key, proving it holds the private key corresponding to the certificate.
Client verifies the certificate chain, verifies the server's proof, and the handshake is done. The entire exchange takes 1 round trip (down from 2 in TLS 1.2). Everything after this is symmetric encryption.
What can still go wrong
Certificate mis-issuance: a CA issues a certificate for a domain to someone who doesn't own it. Certificate Transparency (CT) logs are the main defence — every issued certificate is logged publicly, and browsers check the log. Mis-issued certificates get detected quickly.
Expired certificates: the browser rejects them. Not a security issue but a reliability one. Let's Encrypt's 90-day certificates with automated renewal largely solved this operationally.
Weak cipher suites: TLS 1.3 removed all weak options. Servers that still support TLS 1.0 or 1.1 are downgrade targets. ssl_protocols TLSv1.2 TLSv1.3; in your nginx config is the minimum.
Where this leaves us
A TLS connection combines a hash (for certificate verification), public-key cryptography (for the certificate signature), ECDHE key exchange (for deriving the session secret), and AES-GCM (for the session itself). Everything in this course appears in that 100ms handshake.
The Digital Signatures tool lets you create and verify signatures using the same RSA-PSS and ECDSA algorithms used inside TLS — try signing a message with a generated key pair and verifying it with just the public key.