How does the modern TLS 1.3 handshake work, step by step?

6 minadvancedtls-1.3tls-handshakeecdhe

Quick Answer

TLS 1.3 completes its handshake in one round trip. The client sends a ClientHello with its supported settings and a guessed key share. The server replies with its own key share, certificate, and a signature, all in one flight. Both sides now have enough information to compute the same shared secret, so encrypted application data can be sent right after — no separate round trip needed.

Detailed Answer

TLS 1.3's biggest design goal was cutting the handshake down to one round trip (1-RTT). It does this by having the client guess which key-exchange method the server will pick, and sending its part of the key exchange immediately, instead of waiting to be told what to use.

Client                                                    Server

ClientHello
+ key_share (client's guessed ECDHE public value)
+ supported cipher suites, TLS version
   ------------------------------------------------->

                                          ServerHello
                                          + key_share (server's ECDHE public value)
                                          {EncryptedExtensions}
                                          {Certificate}
                                          {CertificateVerify}   <- signature proving
                                                                    server owns the
                                                                    certificate's key
                                          {Finished}
   <-------------------------------------------------

{Finished}
Application Data (encrypted)
   ------------------------------------------------->
                                          Application Data (encrypted)
   <-------------------------------------------------

Step by step:

  1. ClientHello — the client sends its supported TLS versions, cipher suites, and, critically, an ECDHE key share for the group it expects the server to pick.
  2. ServerHello — the server picks a cipher suite and TLS version, and sends back its own ECDHE key share.
  3. At this point, both sides can independently compute the same shared secret from the two ECDHE key shares. Everything from here on is encrypted.
  4. Certificate + CertificateVerify — the server sends its certificate, plus a signature proving it holds the certificate's private key.
  5. Finished — both sides send a Finished message, a hash over the whole handshake, to confirm nothing was tampered with.
  6. Application data — the client can start sending encrypted HTTP requests right after step 1-2, without waiting for the server's certificate to be verified, because it already has a shared secret.

The result: encrypted application data can begin after just one round trip, instead of the two round trips TLS 1.2 needed. The next question compares this directly against the older TLS 1.2 flow.