What happens during the TLS handshake (TLS 1.2 view), in four phases?

Question

Accepted Answer

Phase A: negotiate security parameters. Phase B: server authentication + key exchange. Phase C: optional client authentication + key exchange completion. Phase D: switch on the cipher suite and finish.
Phase A — Parameter negotiation:
Client → Server: ClientHello
   { random, session ID, supported cipher suites, supported compression }
Server → Client: ServerHello
   { random, session ID, chosen cipher suite }

Phase B — Server authentication & key exchange:
Server → Client: Certificate           (server's X.509 chain)
Server → Client: ServerKeyExchange     (e.g. DH public param, signed)
Server → Client: CertificateRequest    (optional, only for mTLS)
Server → Client: ServerHelloDone

Phase C — Client key exchange (and optional client cert):
Client → Server: Certificate           (only if requested, mTLS)
Client → Server: ClientKeyExchange     (RSA-encrypted pre-master OR client's DH public)
Client → Server: CertificateVerify     (only if client cert sent)

Both sides now derive the master secret from the pre-master + the two random nonces.
Phase D — Finalisation:
Client → Server: ChangeCipherSpec     (now using the new keys)
Client → Server: Finished              (encrypted MAC of all prior messages)
Server → Client: ChangeCipherSpec
Server → Client: Finished

The Finished messages are integrity-protected MACs over the entire handshake transcript — defeats downgrade attacks.
TLS 1.3 changes: combined Phases A+B into one round trip, removed RSA key exchange entirely (mandatory DHE/ECDHE for Perfect Forward Secrecy), removed CCS messages, removed weak cipher suites. Result: 1-RTT handshake (vs 2-RTT in 1.2), and resumed sessions are 0-RTT.
Tip: Use openssl s_client -connect host:443 -msg to see all handshake messages in hex. It's the most concrete way to understand what's actually happening.