What happens in a TLS 1.2 handshake, message by message?

ClientHello → ServerHello, Certificate, ServerKeyExchange, ServerHelloDone → ClientKeyExchange, ChangeCipherSpec, Finished → ChangeCipherSpec, Finished. Two round trips after TCP's own handshake; then the application data flows encrypted with the session keys.

* The handshake up to ChangeCipherSpec is readable in a capture; the Finished messages and all application data are encrypted. *

1. ClientHello (client → server): the TLS versions and cipher suites the client supports, and 32 random bytes, the client random.
2. ServerHello: the version and cipher suite the server chose, and the server random.
3. Certificate: the server's certificate. The client checks it against its trust anchor and the host name.
4. ServerKeyExchange (with ECDHE suites): the server's temporary Diffie-Hellman public value, signed with the certificate's private key. The signature proves the server holds that key.
5. ServerHelloDone: the server's half of the negotiation is complete. (A server that wants a client certificate sends a CertificateRequest before this.)
6. ClientKeyExchange: the client's temporary Diffie-Hellman public value. Both sides can now compute the same premaster secret, and from it plus both randoms the session keys.
7. ChangeCipherSpec + Finished (client): "from now on I encrypt", followed by a check value over the whole handshake, already encrypted.
8. ChangeCipherSpec + Finished (server): the same in the other direction.

Then the HTTP request travels as encrypted Application Data records. TLS 1.3 compresses this into one round trip and encrypts everything after the ServerHello, including the certificate.

Go deeper:

• The Illustrated TLS 1.2 Connection — every byte of a real ECDHE-RSA handshake, decoded and explained.
• Computerphile — TLS Handshake Explained — how key exchange and certificate check fit together, drawn out step by step.
• RFC 5246 — TLS 1.2 — the specification, with the full handshake message flow in section 7.3.