$TLS Handshake

The TLS handshake negotiates security parameters, authenticates peers, and derives traffic keys.

Jul 11, 2026

The TLS handshake establishes cryptographic keys and authenticates the connection before ordinary application data is exchanged. TLS 1.2 and TLS 1.3 use different message flows and should not be represented by one sequence.

TLS 1.2 With ECDHE

A common TLS 1.2 handshake is:

Client                                              Server
ClientHello                 ->
                            <- ServerHello
                            <- Certificate
                            <- ServerKeyExchange
                            <- ServerHelloDone
ClientKeyExchange           ->
ChangeCipherSpec, Finished  ->
                            <- ChangeCipherSpec, Finished
Application Data            <-> Application Data

The server’s signed ephemeral ECDHE parameters authenticate the key exchange. Both peers derive traffic keys from the shared secret and handshake transcript. Other TLS 1.2 cipher suites have different details; RSA key exchange, for example, does not provide forward secrecy and should not be enabled.

TLS 1.3

A typical full TLS 1.3 handshake is:

Client                                              Server
ClientHello + key_share      ->
                             <- ServerHello + key_share
                             <- EncryptedExtensions
                             <- Certificate
                             <- CertificateVerify
                             <- Finished
Finished                     ->
Application Data             <-> Application Data

TLS 1.3 encrypts most handshake messages after ServerHello, removes legacy key-exchange modes, and normally completes in one network round trip. Cipher-suite names cover record protection and hashing; authentication and key exchange are negotiated separately.

Ephemeral (EC)DHE provides forward secrecy: later compromise of the certificate’s private key does not reveal recorded sessions whose ephemeral secrets are gone.

Resumption And 0-RTT

Session resumption can authenticate a connection using a pre-shared key established by an earlier session. TLS 1.3 can optionally send early application data before the resumed handshake completes.

0-RTT data has weaker security properties:

• it is not inherently protected against replay across connections;
• it is not forward secret in the same way as ordinary 1-RTT application data;
• clients cannot know the server deployment’s complete anti-replay behavior.

Only application operations explicitly designed to tolerate replay should use 0-RTT. Transfers, purchases, and other side-effecting operations must not rely on TLS alone to make early data safe.

Further Reading

• RFC 5246: TLS 1.2
• RFC 8446: TLS 1.3