Every cryptographic primitive covered in this track — symmetric ciphers, hash functions, MACs, public-key cryptography, digital signatures — converges in a single protocol: TLS. The handshake is where all of these pieces assemble into a secure channel.
Two strangers meet in a crowded room and need to have a private conversation. First, one proves their identity (certificate verification). Then, they agree on a secret language only they understand (key exchange). Finally, they switch to that language for the rest of the conversation (symmetric encryption). The handshake is the introduction; the symmetric channel is the conversation.
TLS 1.3 completes this introduction in a single round trip — one message from client to server, one message back. Every prior version of TLS required at least two round trips. The reduction is not just a performance optimization; it is the result of eliminating insecure options that made the older handshakes complex.
TLS 1.2 supported dozens of cipher suite combinations, including many that were known to be weak. The protocol’s flexibility was its vulnerability — downgrade attacks tricked clients and servers into using weak cipher suites even when both supported strong ones. TLS 1.3 stripped the options to a small set of known-good configurations. Less choice, more security.
ClientHello: the client sends its supported cipher suites, supported key exchange groups (e.g., X25519, P-256), and — critically — key shares for its preferred groups. By sending key shares upfront, the client enables the server to complete the key exchange in its first response, saving a round trip.
ServerHello: the server selects a cipher suite and a key exchange group, and sends its own key share. At this point, both sides can compute the shared secret using ECDHE. The server also sends its certificate and a CertificateVerify message — a digital signature over the handshake transcript, proving it holds the private key corresponding to the certificate.
Finished: both sides exchange Finished messages — MACs over the entire handshake transcript, computed with the newly derived keys. This proves that neither side’s messages were tampered with during the handshake. After the Finished messages, all subsequent data is encrypted with the session keys.
Every message in the handshake is hashed into a running transcript. The CertificateVerify signature covers this transcript, and the Finished MACs cover it as well. This means any tampering with any handshake message — by a man-in-the-middle attacker, for example — is detected. The transcript binding is what makes TLS 1.3 resistant to downgrade attacks: an attacker who modifies the ClientHello to remove strong cipher suites will be caught when the Finished MACs don’t match.
A cipher suite specifies the exact combination of algorithms used for a TLS connection. In TLS 1.3, a cipher suite name encodes three choices:
TLS_AES_256_GCM_SHA384: AES-256-GCM for symmetric encryption and authentication, SHA-384 for the handshake hash. The key exchange algorithm (always ECDHE in TLS 1.3) is negotiated separately.
TLS_CHACHA20_POLY1305_SHA256: ChaCha20-Poly1305 for symmetric encryption and authentication, SHA-256 for the handshake hash. Preferred on devices without AES hardware acceleration.
TLS_AES_128_GCM_SHA256: AES-128-GCM with SHA-256. The most commonly negotiated suite on the modern web.
TLS 1.3 supports exactly five cipher suites. TLS 1.2 supported over 300. The reduction is intentional — every eliminated option was either insecure or redundant.
No more RSA key exchange — the server’s RSA key was used to encrypt the premaster secret directly, meaning a compromised server key could decrypt all past sessions. No more CBC mode ciphers — CBC in TLS was the source of BEAST, Lucky13, and POODLE. No more static Diffie-Hellman — only ephemeral key exchange is permitted. No more MD5 or SHA-1 in the handshake. Every removal corresponds to a real-world attack.
Forward secrecy (also called perfect forward secrecy) means that compromising a server’s long-term private key does not compromise past sessions. TLS 1.3 achieves this through ephemeral Diffie-Hellman: every connection generates fresh key pairs for the key exchange. The session key is derived from these ephemeral keys. Once the connection ends, the ephemeral private keys are discarded.
If an attacker records encrypted traffic today and later steals the server’s private key, they still cannot decrypt the recorded sessions. The server’s private key is used only for authentication (signing the CertificateVerify message), not for key exchange. The session keys were derived from ephemeral keys that no longer exist.
In TLS 1.2, RSA key exchange was still an option. With RSA key exchange, the client encrypts the premaster secret to the server’s RSA public key. If the server’s RSA private key is later compromised, an attacker who recorded the handshake can decrypt the premaster secret and derive all session keys. This is not forward-secret. Intelligence agencies are known to record encrypted traffic for later decryption — a practice called “harvest now, decrypt later.” TLS 1.3 eliminated RSA key exchange entirely, making forward secrecy a mandatory property of every connection.
When the server sends its certificate, the client must verify the entire chain of trust before proceeding. This verification has multiple steps:
Chain building: the client constructs a path from the leaf certificate (the server’s) through one or more intermediate CAs to a trusted root CA. Each certificate in the chain is signed by the next one up.
Signature verification: the client verifies each signature in the chain using the issuer’s public key. If any signature is invalid, the handshake fails.
Name matching: the client checks that the domain it connected to appears in the leaf certificate’s Subject Alternative Name (SAN) extension. A certificate for example.com is not valid for api.example.com unless the SAN includes it or a wildcard like *.example.com.
Validity period: the certificate’s notBefore and notAfter dates must bracket the current time.
Revocation check: the client checks whether the certificate has been revoked, typically via OCSP stapling (the server provides a signed, timestamped OCSP response during the handshake).
For high-security applications, standard certificate verification may not be sufficient — a compromised CA could issue a fraudulent certificate for a target domain. Certificate pinning binds a specific public key (or set of keys) to a domain. The client rejects any certificate for that domain that doesn’t match the pinned key, even if the certificate chain is otherwise valid. HPKP (HTTP Public Key Pinning) was deprecated due to operational risks, but pinning remains common in mobile applications and service-to-service communication.
HTTPS: every time a browser loads a page over https://, a TLS handshake occurs (or is resumed from a previous session). The handshake is invisible — the browser handles certificate verification, cipher suite negotiation, and key exchange automatically. Tools like openssl s_client -connect example.com:443 allow the handshake to be observed directly.
mTLS (mutual TLS): standard TLS authenticates only the server. Mutual TLS requires both sides to present certificates. The server verifies the client’s certificate just as the client verifies the server’s. mTLS is the standard authentication mechanism for service-to-service communication in zero-trust architectures — Kubernetes service meshes (Istio, Linkerd) use mTLS by default.
Let’s Encrypt and ACME: the Automated Certificate Management Environment (ACME) protocol automates certificate issuance and renewal. A client (certbot, Caddy, Traefik) proves domain ownership to Let’s Encrypt by responding to a challenge (HTTP-01 or DNS-01), and receives a signed X.509 certificate. Certificates are valid for 90 days and are renewed automatically. This eliminated the cost and manual effort that previously made HTTPS adoption slow.
Debugging TLS: curl -v https://example.com shows the negotiated cipher suite, certificate chain, and TLS version. openssl s_client -connect example.com:443 -showcerts dumps the full certificate chain. testssl.sh audits a server’s TLS configuration for known weaknesses.
This lesson establishes:
Next: Quiz: Crypto Foundations