How TLS handshake works and why HTTPS is secure
TLS 1.3 handshake, ClientHello, ServerHello, certificate exchange, key agreement, symmetric encryption, forward secrecy
The TLS Handshake
TLS (Transport Layer Security) wraps HTTP in an encrypted tunnel. Before any HTTP bytes move, a handshake establishes shared encryption keys. Here is how TLS 1.3 does it in one round-trip.
TLS 1.3 handshake steps
1. ClientHello. The client sends supported TLS versions, cipher suites, and its key share (an ephemeral public key for the chosen key exchange algorithm, usually X25519).
2. ServerHello. The server picks a cipher suite, sends its own key share, and immediately derives the session keys. Subsequent messages are already encrypted.
3. Certificate + Verify. The server sends its certificate and proves it holds the private key by signing a hash of the handshake transcript.
4. Client Finished. The client verifies the certificate chain against trusted CAs, checks the domain matches, and sends its Finished message.
Both sides now have identical symmetric session keys derived from both key shares. All HTTP traffic is encrypted from here.
Forward secrecy
TLS 1.3 mandates ephemeral key exchange. If your private key is stolen later, past sessions cannot be decrypted because the session key was derived from a throwaway ephemeral key, not your long-term private key. TLS 1.2 with RSA key exchange lacked this — a stolen private key could decrypt all past captured traffic.
# Inspect a site's TLS version and cipher suite
openssl s_client -connect example.com:443 -tls1_3