TLS handshake
The opening phase of a TLS connection that agrees the protocol version and cipher suite, commonly authenticates the server with its certificate, and derives the session keys.
The TLS handshake is the negotiation that runs before a TLS connection carries any application data. The client offers versions and cipher suites it supports, and the server chooses. The server proves its identity with a certificate that chains to a trusted authority through public key infrastructure, plus proof (in current versions, a signature) that it holds the matching private key. The two sides run a key exchange, commonly ephemeral Diffie-Hellman, and derive session keys from it. The server may also ask for a client certificate, which gives mutual authentication. Once the handshake ends, data is protected with symmetric encryption.
TLS 1.3, defined in RFC 8446, reshaped the handshake. A full handshake takes one round trip instead of the two used by TLS 1.2 (RFC 5246). Static RSA key exchange was removed, so every full 1.3 handshake uses an ephemeral exchange and gains forward secrecy, and more of the handshake is encrypted, including the server’s certificate. An optional zero round-trip mode (0-RTT) lets a returning client send data at once, but RFC 8446 warns that this early data can be replayed, a replay attack risk the application has to handle.
Exam relevance: a scenario may ask which phase authenticates the server, or what separates TLS 1.3 from 1.2. Candidates are expected to place authentication and key agreement in the handshake and bulk encryption after it.