Send a password to example.com and find out exactly what the café wi-fi can read.
- tls version
- proposed 1.3
- cipher suite
- —
- key exchange
- —
- server_name (sni)
- example.com
- certificate
- —
- issuer
- —
- chain check
- unverified
- session keys
- —
chosen by the server
encrypts and authenticates together
ephemeral — forward secrecy
sent in the clear, before any keys
the identity claim
already trusted by this machine
name, dates, signature
both sides computed the same secret
HTTPS still needs a transport underneath it. What gets built first, before any encryption?
One password, one request. Watch the four moves that have to happen before a single byte of it can leave the machine — and note which one is about identity rather than secrecy.
The padlock does not mean the site is safe, and it does not hide your password from the site. It means one thing: the bytes are unreadable to everyone between you and whoever holds that certificate. The server decrypts and reads every word.
TLS is not encrypted HTTP. It is a separate layer underneath: HTTP is written exactly as before, then handed to TLS, which seals it. That is why a GET looks identical on both wires — only its wrapping changed.
Encryption is the easy half. The certificate is the hard half: without it you would have a perfectly private conversation with an impostor.
Underneath sits a plain TCP handshake. Plaintext DNS can expose the hostname before TLS starts, and plaintext SNI exposes it in this lab; encrypted DNS and ECH can reduce those leaks. Same messages as the HTTP lab, sealed.
Send a password to example.com and find out exactly what the café wi-fi can read.
- What can the café wi-fi still see during this HTTPS request?
- Why does the browser check the certificate?
Read it now and keep it in mind — the answer is in what you are about to watch.