This cheat sheet covers the TLS handshake, the process that lets a browser and server create a secure connection before exchanging private data. Students need it because HTTPS, APIs, online banking, and many secure apps depend on TLS. Understanding the handshake helps explain how encryption, authentication, and integrity work together on the web.
The most important ideas are certificate verification, key exchange, shared secret creation, and symmetric session encryption. Modern TLS, especially TLS 1.3, uses ephemeral Diffie-Hellman to create fresh session keys. The client verifies the server certificate using a trusted certificate authority, then both sides derive matching keys without sending the secret itself.
Key Facts
- TLS protects data using confidentiality, integrity, and authentication between a client and a server.
- The handshake starts with ClientHello, which sends supported TLS versions, cipher suites, random data, and key share information.
- The server replies with ServerHello, selecting the TLS version, cipher suite, random data, and its key share.
- A server certificate binds a domain name to a public key and must be signed by a trusted certificate authority.
- Certificate verification checks that the certificate is not expired, matches the domain, chains to a trusted CA, and has a valid signature.
- In Diffie-Hellman key exchange, both sides compute the same shared secret using their private key and the other side's public key.
- A simplified key derivation rule is session keys = KDF(shared secret, client random, server random).
- After the handshake, application data is encrypted with faster symmetric encryption such as AES-GCM or ChaCha20-Poly1305.
Vocabulary
- TLS
- Transport Layer Security is a protocol that secures network communication using encryption, authentication, and integrity checks.
- Handshake
- A handshake is the setup process where the client and server agree on security settings and create shared session keys.
- Certificate
- A certificate is a digitally signed document that connects a website's identity to its public key.
- Certificate Authority
- A certificate authority is a trusted organization that signs certificates to help prove that a public key belongs to a real domain.
- Key Exchange
- Key exchange is the method used by two parties to create a shared secret over an insecure network.
- Session Key
- A session key is a temporary symmetric key used to encrypt and decrypt data during one secure connection.
Common Mistakes to Avoid
- Confusing TLS with HTTPS is incorrect because HTTPS is HTTP running over TLS, while TLS is the security protocol itself.
- Assuming the certificate encrypts all data is wrong because the certificate mainly proves identity and provides a public key for authentication.
- Thinking the shared secret is sent across the network is wrong because Diffie-Hellman lets both sides compute it without transmitting it.
- Ignoring certificate validation is dangerous because encryption without authentication can still allow a man-in-the-middle attack.
- Mixing up asymmetric and symmetric encryption is a common error because TLS uses asymmetric methods during setup but usually uses symmetric encryption for the actual data.
Practice Questions
- 1 A browser receives a certificate for example.com, but the user visited bank.example.com. What certificate name check could fail, and why?
- 2 A TLS 1.3 connection uses a client random, a server random, and a shared secret. Write the simplified key derivation expression for the session keys.
- 3 If a certificate expires on 2026-04-01 and today's date is 2026-05-10, should the browser trust it? Explain the validation rule.
- 4 Why does TLS use symmetric encryption after the handshake instead of using public key encryption for all application data?
Understanding TLS Handshake Reference
A key idea is that the handshake messages are themselves protected before ordinary web data begins. Each side keeps a record called the handshake transcript. Near the end, each side sends a Finished message.
This message proves that it derived the correct secret and saw the same earlier messages. If an attacker changed a chosen encryption method or replaced a key share while messages were traveling, the transcript check fails. This prevents downgrade attacks, where someone tries to force an old, weaker security setting.
The certificate contains more than a public key. It has names that the certificate is allowed to represent, a validity period, its issuer, and a digital signature. Browsers usually build a chain from the website certificate through one or more intermediate certificates to a trusted root certificate stored on the device.
Root certificates are powerful trust anchors. A browser or operating system updates this trusted list carefully.
A certificate can be technically valid yet still be rejected when its name does not match the site being visited. This is why typing a different subdomain can produce a warning.
Authentication is not the same as secrecy. Encryption can hide a message, but it does not automatically prove who received it. The server proves control of its private key by signing parts of the handshake or by creating a valid proof tied to that key exchange.
The browser can verify this proof using the public key in the certificate. Some systems use client certificates too.
Schools, workplaces, and government services may use them to identify a device or person without relying only on a password. Most public websites authenticate only the server.
Fresh temporary key material has an important security benefit called forward secrecy. Suppose a server private key is stolen sometime in the future. An attacker who recorded older encrypted connections should still be unable to read them, because those connections used temporary private values that were discarded after use.
Students should distinguish this temporary key exchange material from the long term certificate key. They have different jobs.
One helps establish a new connection. The other helps prove that the server is the real owner of the named domain.
After setup, the connection uses separate traffic keys for each direction. Data from browser to server is protected with one key, while data from server to browser uses another. Modern modes such as AES-GCM check both secrecy and integrity together.
They use a unique number for every encrypted record. Reusing that number with the same key can seriously weaken security, so TLS tracks record numbers automatically. In real life, certificate warnings, incorrect device clocks, captive Wi Fi portals, and outdated software can interrupt this process.
A warning does not always mean an attack, but bypassing it removes an important check. TLS can resume a recent connection to save time, though early data in some resumed connections needs special care because it can sometimes be replayed.