What is TLS Handshake?

Before any application data moves, a TLS connection has to establish three things: which version and algorithms both sides support, whether the server is who it claims to be, and what keys to use for the session. That negotiation is the handshake, and it is where most externally observable TLS problems — weak protocol versions, bad chains, missing forward secrecy — are visible.

TLS 1.3

TLS 1.3 completes the handshake in a single round trip. The client sends ClientHello with its supported parameters and a key share for the group it guesses the server will pick; the server replies with its own key share, its certificate chain and a signature proving possession of the private key; both sides derive the same secrets and everything after the server’s first flight is encrypted. Key exchange is always ephemeral, so perfect forward secrecy is not optional, and the legacy cipher suites that caused most historical failures were removed from the protocol.

TLS 1.3 also offers 0-RTT resumption, sending application data with the first message. It is faster, but the early data is replayable, so it is only appropriate for idempotent requests.

TLS 1.2 and before

TLS 1.2 needs two round trips and negotiates far more: the cipher suite is chosen from a list, key exchange may be ephemeral (ECDHE, DHE) or static RSA without forward secrecy, and parts of the handshake travel in the clear. Its flexibility is the source of its weaknesses — downgrade attacks such as POODLE depended on a client retrying with an older protocol, which the TLS_FALLBACK_SCSV signalling mechanism was introduced to prevent. Anything older than TLS 1.2 is deprecated and should be disabled.

Extensions worth knowing

SNI (Server Name Indication) — the client names the host it wants, so one address can serve many certificates. In TLS 1.2 it is sent in plaintext, which is why TLS alone does not hide which site you visited.
ALPN — negotiates the application protocol, such as HTTP/2.
OCSP stapling — attaches a signed revocation status, discussed under OCSP.

What the handshake reveals externally

Because the handshake is unauthenticated until the certificate is verified, anyone can initiate one and learn a great deal: supported versions and cipher suites, the certificate and its chain, expiry dates, and often the software behind it from its ordering preferences. That makes handshake inspection a standard part of external assessment, sitting alongside service fingerprinting and banner grabbing.

See cipher suite, certificate authority, self-signed certificate, Heartbleed and TLS and certificates.