Cryptography › Module 3 › Lesson 1
How TLS Handshake Works
Follow the TLS handshake from ClientHello to encrypted application data
Opening
HTTPS is HTTP inside a TLS tunnel
When you see the padlock, your browser and the server already finished a cryptographic handshake. Understanding that dance helps you debug cert errors, MITM risks, and why cleartext HTTP is dangerous on hostile networks.
1. Handshake in Plain Language
1. ClientHello — “Here are the TLS versions and cipher suites I support.” 2. ServerHello — picks parameters and sends its certificate 3. Key exchange — agree on secrets (classic RSA key transport or modern Diffie–Hellman variants) 4. Finished — both sides confirm; then application data (HTTP) is encrypted Exact messages evolve with TLS 1.2 vs 1.3, but the goals stay: authenticate, negotiate, protect.
2. What You Gain
Confidentiality
Eavesdroppers on Wi-Fi see ciphertext, not passwords.
Integrity
Tampering with bytes is detected.
Server authentication
Certificate proves you reached the expected name (when users check!).
TLS ≠ “the site is honest”
A phishing site can have a valid cert for its own evil domain. TLS protects the pipe; you still verify the name.
Knowledge Check
HTTPS is best described as:
Multiple choice
Knowledge Check
True or False: During the TLS handshake the server usually presents a certificate.
True or False
Knowledge Check
After the handshake, bulk HTTP data is typically protected with:
Multiple choice