{"id":4241,"date":"2026-11-08T05:57:00","date_gmt":"2026-11-08T05:57:00","guid":{"rendered":"https:\/\/www.ucartz.com\/blog\/tls-handshake\/"},"modified":"2026-11-09T22:05:23","modified_gmt":"2026-11-09T22:05:23","slug":"tls-handshake","status":"publish","type":"post","link":"https:\/\/www.ucartz.com\/blog\/tls-handshake\/","title":{"rendered":"TLS Handshake Explained: Steps in TLS 1.3 and TLS 1.2"},"content":{"rendered":"\n

The TLS handshake is the short conversation a browser and a web server have before any HTTPS page data is sent. In it they agree on a TLS version and cipher, create shared encryption keys, and the server proves with its certificate that it really is the site you asked for. With TLS 1.3 this takes one network round trip; with the older TLS 1.2 it takes two. People still call it the “SSL handshake”, but SSL itself is long retired: RFC 9325<\/a> says implementations must not negotiate SSL 2 or SSL 3.<\/p>\n\n\n\n

\"Terminal
A real TLS 1.3 handshake with example.com: protocol version, cipher suite and the server certificate<\/figcaption><\/figure>\n\n\n\n

What the handshake has to achieve<\/h2>\n\n\n\n

The TLS 1.3 standard, RFC 8446<\/a>, splits the handshake into three phases:<\/p>\n\n\n\n

    \n
  1. Key exchange:<\/strong> agree on the cryptographic parameters and create shared keying material. Everything after this phase is encrypted.<\/li>\n\n\n\n
  2. Server parameters:<\/strong> settle the remaining options, such as which application protocol (HTTP\/2 or HTTP\/1.1) to use and whether the client must show a certificate too.<\/li>\n\n\n\n
  3. Authentication:<\/strong> the server proves it owns the private key for its certificate, and both sides confirm that nobody tampered with the messages so far.<\/li>\n<\/ol>\n\n\n\n

    If any part fails, the connection is closed, often with a TLS alert message, and no page data is sent at all. That is what the browser reports as a handshake or secure connection error.<\/p>\n\n\n\n

    The TLS 1.3 handshake, step by step<\/h2>\n\n\n\n

    To see the real messages, we ran nginx 1.31.6 in a Docker container with a test certificate for shop.example.test<\/code> and connected with the OpenSSL 3.5.8 s_client<\/code> tool. The -msg<\/code> option prints every handshake message (we removed the record-header lines):<\/p>\n\n\n\n

    $ openssl s_client -connect shop.example.test:443 -servername shop.example.test -tls1_3 -msg -brief\n>>> TLS 1.3, Handshake [length 05c0], ClientHello\n<<< TLS 1.3, Handshake [length 04ba], ServerHello\n<<< TLS 1.3, ChangeCipherSpec [length 0001]\n<<< TLS 1.3, Handshake [length 000a], EncryptedExtensions\n<<< TLS 1.3, Handshake [length 01bd], Certificate\n<<< TLS 1.3, Handshake [length 0050], CertificateVerify\n<<< TLS 1.3, Handshake [length 0034], Finished\n>>> TLS 1.3, ChangeCipherSpec [length 0001]\n>>> TLS 1.3, Handshake [length 0034], Finished\nProtocol version: TLSv1.3\nCiphersuite: TLS_AES_256_GCM_SHA384\nNegotiated TLS1.3 group: X25519MLKEM768<\/code><\/pre>\n\n\n\n
    >>><\/code> is the client sending, <<<<\/code> is the server answering. Here is what each message does:<\/p>\n\n\n\n
      \n
    1. ClientHello:<\/strong> the client sends a random number, the TLS versions and cipher suites it supports, and its half of a key exchange in the key_share<\/code> extension. It also names the site it wants (SNI, server name indication) and the protocols it can speak (ALPN, for example h2<\/code> for HTTP\/2).<\/li>\n\n\n\n
    2. ServerHello:<\/strong> the server picks the version and cipher suite and sends its own key share. From these two messages both sides calculate the same secret, and every message after this point is encrypted.<\/li>\n\n\n\n
    3. EncryptedExtensions:<\/strong> the answers to the client’s other requests, such as the chosen ALPN protocol.<\/li>\n\n\n\n
    4. Certificate and CertificateVerify:<\/strong> the server sends its certificate chain, then a signature over the whole handshake made with the certificate’s private key. That signature is the proof of identity: a copied certificate is useless without the key.<\/li>\n\n\n\n
    5. Finished (both sides):<\/strong> a MAC over the entire handshake. If anyone changed a single byte on the way, the values would not match and the connection would stop.<\/li>\n<\/ol>\n\n\n\n
      The two ChangeCipherSpec<\/code> lines are not real TLS 1.3 messages. RFC 8446 (Appendix D.4) describes this “middlebox compatibility mode”: dummy records that make the handshake look like TLS 1.2 so that old firewalls and proxies let it through.<\/p>\n\n\n\n
      Note the group X25519MLKEM768<\/code> and the large ClientHello (0x05c0, 1,472 bytes). OpenSSL 3.5 added hybrid post-quantum key exchange and offers it by default. The OpenSSL documentation warns that in rare cases the bigger ClientHello no longer fits in one TCP segment and badly behaved firewall software can break the handshake, so keep this in mind if a firewall is in the path and only new clients fail.<\/p>\n\n\n\n
      The TLS 1.2 handshake: one extra round trip<\/h2>\n\n\n\n
      The same server and client, forced to TLS 1.2 with -tls1_2<\/code>:<\/p>\n\n\n\n
      >>> TLS 1.2, Handshake [length 00d4], ClientHello\n<<< TLS 1.2, Handshake [length 0045], ServerHello\n<<< TLS 1.2, Handshake [length 01ba], Certificate\n<<< TLS 1.2, Handshake [length 0074], ServerKeyExchange\n<<< TLS 1.2, Handshake [length 0004], ServerHelloDone\n>>> TLS 1.2, Handshake [length 0025], ClientKeyExchange\n>>> TLS 1.2, ChangeCipherSpec [length 0001]\n>>> TLS 1.2, Handshake [length 0010], Finished\n<<< TLS 1.2, Handshake [length 00da], NewSessionTicket\n<<< TLS 1.2, Handshake [length 0010], Finished\nProtocol version: TLSv1.2\nCiphersuite: ECDHE-ECDSA-AES256-GCM-SHA384<\/code><\/pre>\n\n\n\n
      (The server also sends a ChangeCipherSpec before its Finished; OpenSSL shows it only as a bare record header, so it is not in the list.) In TLS 1.2 the client does not send a key share in its first message. It has to wait for the server’s hello, certificate and key exchange, then send its own key exchange, and only after the server’s Finished comes back can the page be requested. The certificate also travels unencrypted, so anyone watching the network can read it.<\/p>\n\n\n\n
      <\/th>TLS 1.2<\/th>TLS 1.3<\/th><\/tr><\/thead>
      Round trips for a full handshake<\/td>2<\/td>1<\/td><\/tr>
      Certificate sent<\/td>In the clear<\/td>Encrypted<\/td><\/tr>
      Key exchange<\/td>ECDHE, DHE or static RSA<\/td>(EC)DHE, PSK, or both; static RSA and static Diffie-Hellman removed, so every public-key exchange has forward secrecy<\/td><\/tr>
      Ciphers<\/td>Many, including legacy CBC suites<\/td>AEAD only (AES-GCM, ChaCha20-Poly1305, AES-CCM)<\/td><\/tr>
      Resumed connection<\/td>1 round trip (abbreviated handshake)<\/td>1 round trip, or 0-RTT with early data<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      We timed it: 1 round trip versus 2<\/h2>\n\n\n\n
      To make the difference visible, we added 100 ms of delay to the server container’s network with Linux tc netem<\/code>, so every round trip took about 100 ms, and asked curl 8.22.0 to report how long the TLS part took. Three runs of each gave the same picture:<\/p>\n\n\n\n
      Protocol<\/th>TLS handshake time<\/th>Round trips<\/th><\/tr><\/thead>
      TLS 1.3<\/td>102 to 106 ms<\/td>1<\/td><\/tr>
      TLS 1.2<\/td>205 to 213 ms<\/td>2<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      The handshake time is curl’s time_appconnect<\/code> minus time_connect<\/code>. The cryptography itself took a few milliseconds; nearly all the time was waiting for packets. That is why the round-trip count matters so much for visitors far from your server, and why moving from TLS 1.2 to 1.3 makes the first page load feel faster on slow or distant connections.<\/p>\n\n\n\n
      Session resumption and 0-RTT<\/h2>\n\n\n\n
      After a handshake the server can send a NewSessionTicket<\/code>. curl showed two of them arriving after our TLS 1.3 handshake. On the next visit the client presents the ticket, and the server can skip the certificate step. We saved the session with -sess_out<\/code> and reconnected with -sess_in<\/code>:<\/p>\n\n\n\n
      >>> TLS 1.3, Handshake [length 06ef], ClientHello\n<<< TLS 1.3, Handshake [length 04c0], ServerHello\n<<< TLS 1.3, Handshake [length 000a], EncryptedExtensions\n<<< TLS 1.3, Handshake [length 0034], Finished\n>>> TLS 1.3, Handshake [length 0034], Finished\nReused, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384<\/code><\/pre>\n\n\n\n
      No Certificate and no CertificateVerify this time. TLS 1.2 resumption behaved the same way: ServerHello, then Finished from both sides, one round trip instead of two.<\/p>\n\n\n\n
      TLS 1.3 can go one step further with 0-RTT<\/strong> (early data): a returning client sends its first request together with the ClientHello. RFC 8446 warns that 0-RTT data is not forward secret and that “there are no guarantees of non-replay between connections”, so an attacker could resend it. For that reason nginx has ssl_early_data off<\/code> by default, and the nginx SSL module documentation<\/a> says requests sent in early data are subject to replay attacks. Leave it off unless your application only accepts safe, repeatable requests in early data.<\/p>\n\n\n\n
      How to see a TLS handshake yourself<\/h2>\n\n\n\n
      With curl, the verbose flag prints each handshake step and the result:<\/p>\n\n\n\n
      $ curl -sv https:\/\/shop.example.test\/ -o \/dev\/null\n* ALPN: curl offers h2,http\/1.1\n* TLSv1.3 (OUT), TLS handshake, Client hello (1):\n* TLSv1.3 (IN), TLS handshake, Server hello (2):\n* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):\n* TLSv1.3 (IN), TLS handshake, Certificate (11):\n* TLSv1.3 (IN), TLS handshake, CERT verify (15):\n* TLSv1.3 (IN), TLS handshake, Finished (20):\n* TLSv1.3 (OUT), TLS handshake, Finished (20):\n* SSL connection using TLSv1.3 \/ TLS_AES_256_GCM_SHA384 \/ X25519MLKEM768 \/ id-ecPublicKey\n* ALPN: server accepted h2\n* SSL certificate verified via OpenSSL.<\/code><\/pre>\n\n\n\n
      To check which versions a server accepts, try each one with OpenSSL (on Windows, see how to install OpenSSL<\/a>):<\/p>\n\n\n\n
      openssl s_client -connect example.com:443 -servername example.com -tls1_3 -brief <\/dev\/null\nopenssl s_client -connect example.com:443 -servername example.com -tls1_2 -brief <\/dev\/null<\/code><\/pre>\n\n\n\n
      Always pass -servername<\/code>. Many sites share one IP address, and without SNI the server does not know which certificate to send. Our server refused an old TLS 1.1 attempt like this:<\/p>\n\n\n\n
      error:0A00042E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:ssl\/record\/rec_layer_s3.c:918:SSL alert number 70<\/code><\/pre>\n\n\n\n
      That refusal is correct. RFC 8996<\/a> says TLS 1.0 and TLS 1.1 must not be used, and OpenSSL 3.5 would not even offer TLS 1.1 from the client side until we lowered its security level.<\/p>\n\n\n\n
      Handshake settings worth checking on your server<\/h2>\n\n\n\n