How TLS Handshake Works

TLS 1.3 starts with ClientHello. The client says, in structured extensions rather than a movie “hello packet”: which protocol versions it will accept (TLS 1.3 is 0x0304 in the wire versioning story), which cipher suites it likes (AEAD suites such as AES-GCM or ChaCha20-Poly1305 — authenticated encryption, not “XOR my password”), which elliptic groups it can do Diffie–Hellman on (X25519 and P-256 are the usual names), and a key_share: an ephemeral public value so the server can start agreeing on secrets in the same round trip. It also sends signature_algorithms (which hashes and public-key types it will accept on the certificate) and, almost always, Server Name Indication (SNI): the hostname you typed, so a server that hosts many sites can pick the right certificate. ClientHello is not application data. It is negotiation. Nothing in it is your banking password. The hostname in SNI is often still visible on the wire unless Encrypted Client Hello is in play — which is why “HTTPS encrypts the path” is true for the HTTP path (/account/transfer) and false as a blanket “nobody can see which site I visited.” DNS and SNI are a separate leak story. This lesson’s job is the handshake itself, not pretending metadata vanished.

TLS 1.2 still exists on old appliances. It used more round trips and, in some configurations, RSA key transport: the client encrypted a premaster secret to the server’s RSA public key. TLS 1.3 removed that. Modern key agreement is ephemeral Diffie–Hellman. You do not need to implement the curve math. You need the operational sentence: both sides contribute fresh randomness, derive handshake secrets, then derive application traffic keys. If the server’s long-term private key leaks next year, past recorded sessions that used ephemeral DH should stay confidential — that is the point of forward secrecy. “Conceptual TLS 1.3” in this course means: ClientHello with a key share, ServerHello with a key share, then encrypted handshake messages, then app data. Not a packet-crafting lab. Not a downgrade attack kit.

After ServerHello (chosen version, chosen cipher, server key_share), TLS 1.3 encrypts the rest of the handshake with keys derived from the DH shared secret. Inside that encrypted envelope the server sends EncryptedExtensions, then its certificate chain, then CertificateVerify — a signature over the handshake transcript with the private key that matches the leaf certificate — then Finished (a MAC proving it derived the same secrets). The client checks: is this certificate issued for the name I asked for (SAN match, next lesson), is the chain trusted (CA, the lesson after that), are the dates valid, does CertificateVerify verify? Only then does the client send its own Finished and switch to application traffic keys. The certificate is a signed statement: this public key is bound to this name until this date, vouched by this issuer. It is not a background check on the shop. It is not a malware scan. Key agreement is separate: the cert authenticates who you are talking to (the name), DH produces the symmetric session keys that will encrypt GET /login. Mixing those two jobs is how people say “the padlock means I can type my PIN.” The padlock means the pipe to that hostname is encrypted and the name matched a trusted chain. Phishing sites register look-alike domains, obtain valid certificates for those domains, and show a padlock. TLS did its job. The human still has to read the name.

Bulk data after Finished is symmetric cryptography — AES-GCM or ChaCha20-Poly1305 in practice — because symmetric is fast. The expensive public-key work happened in the handshake. That is the same split you already saw: RSA/ECDSA for authentication and key establishment, AES for the stream. If you disable certificate verification (verify=False, click-through, a corporate SSL-inspect box you did not consent to), you still get encryption to someone — possibly to an attacker who presented any cert. Encryption without authentication is a private conversation with a stranger who picked your pocket. This course never teaches you to install a fake root CA on someone else’s device or to intercept traffic you do not own. Reading example.com’s public certificate is literacy. Becoming a café MITM is a crime.

Once application keys are live, HTTP is encrypted: method, path, query string in typical browser use, headers, body, cookies. An observer on the path sees IP addresses, port 443, roughly how many bytes, and often the SNI hostname. They do not see “password=…” in the POST body if TLS is intact and they are passive. That is the confidentiality win versus cleartext HTTP on hostile Wi-Fi. Integrity is in the AEAD: flipping bits in ciphertext should fail decryption/auth, not silently change “amount=10” to “amount=10000.” Replay and truncation have additional record-layer rules. You do not need to implement them. You need to stop treating HTTP on port 80 as “the same site, just without the icon.”

Create $HOME/cyberlium-lab if it does not exist. Write tls-handshake-notes.txt in your own words: the four beats (ClientHello, certificate, key agreement, app data), the padlock sentence, and the ethics line. Optionally run openssl s_client against example.com (IANA’s documentation host) or a site you operate. That command completes a real TLS handshake as a client and prints the server certificate — the same public object anyone can fetch by visiting the site. It is not a scan of a stranger’s internal network. It is not installing a CA. If openssl is missing, use Git Bash, WSL, or a Linux/macOS box you own; do not “fix” the gap by installing a intercepting proxy. Lock the notes at mode 600.

# DEFENSIVE literacy. YOUR notes. Optional public-cert read.
# NEVER intercept others. NEVER install a fake CA. NEVER sslstrip a café.

mkdir -p "$HOME/cyberlium-lab"
NOTES="$HOME/cyberlium-lab/tls-handshake-notes.txt"

{
  echo "=== TLS HANDSHAKE MAP (conceptual TLS 1.3) ==="
  echo "1 ClientHello: versions, AEAD ciphers, key_share (ephemeral DH), SNI name"
  echo "2 ServerHello + encrypted Certificate + CertificateVerify + Finished"
  echo "3 Key agreement: DH shared secret -> handshake keys -> application traffic keys"
  echo "4 Application data: HTTP inside TLS (HTTPS). Path/body/cookies are ciphertext to a passive observer."
  echo ""
  echo "Padlock means: encrypted path to a name that matched a trusted chain."
  echo "Padlock does NOT mean: the site is honest, not phishing, not malware."
  echo "Phishing sites can obtain valid certs for THEIR own domains."
  echo ""
  echo "HTTPS encrypts the HTTP path. DNS/SNI may still leak the hostname."
  echo "TLS 1.3: no RSA key transport; forward secrecy via ephemeral DH."
  echo ""
  echo "Optional public cert (example.com OR a domain I own) — subject/issuer only:"
  echo "subject:"
  echo "issuer:"
  echo "protocol (expect TLS 1.2 or 1.3):"
  echo ""
  echo "ethics: read public certs; no MITM; no fake CA; no intercepting others"
} > "$NOTES"

# Optional — public certificate on example.com (allowed). Swap for YOUR domain.
# Git Bash / WSL / Linux / macOS. Ctrl+C after the PEM if the session hangs.
echo | openssl s_client -connect example.com:443 -servername example.com -brief 2>/dev/null | head -n 20

chmod 600 "$NOTES"
# Windows without chmod: WSL/Git Bash, or restrict the file in your profile.

# NEVER: mitmproxy / sslstrip / fake root CA on a device you do not own
# NEVER: click through a name-mismatch on a site that asks for secrets
# NEVER: paste live session cookies or passwords into tls-handshake-notes.txt

You now treat HTTPS as HTTP inside a TLS tunnel that authenticated a name and then switched to symmetric session keys. The padlock is a finished handshake, not a character reference. Next — SSL Certificates — you will read the fields the browser actually checks: subject, issuer, validity dates, and Subject Alternative Names. Still no MITM. Still example.com or a host you own when you touch a live cert.