The TLS handshake, explained

Once a TCP connection opens, TLS secures it. Here is what the TLS 1.3 handshake does, step by step, and which part stops an attacker in the middle, with links to the standards themselves.

1. What it is

   TLS secures the connection.

   TLS runs on top of a reliable, in-order stream, typically TCP, and is designed to prevent eavesdropping, tampering and message forgery. The server side is always authenticated, data sent after the handshake is visible only to the endpoints, and it cannot be modified without detection. TLS does not hide the length of the data it sends.

   Source: RFC 8446 (TLS 1.3), section 1

2. How it works

   A short exchange, then encrypted.

   The client sends a ClientHello carrying its key share. The server answers with a ServerHello and its own key share, and everything after that is encrypted. The server then sends its Certificate, a CertificateVerify signature and a Finished message (plus EncryptedExtensions, not drawn in the video). The client replies with its own Finished, and application data flows. The ClientHello and ServerHello themselves are not encrypted. This is the usual certificate-based handshake; pre-shared-key modes differ.

   Source: RFC 8446 (TLS 1.3), section 2

3. Why it matters

   The certificate check stops impostors.

   A client needs to verify that the server's presented identity matches the identity it meant to reach. If it uses a certificate without validating the chain, the connection has no protection against an active man-in-the-middle attack. Full validation (expiry, revocation, trust anchors) is defined in RFC 5280.

   Source: RFC 8446, appendix C.5 and RFC 9525, section 1.1

The takeaway: TLS authenticates the server and protects the data. The handshake swaps key shares, then proves identity with a certificate. And validating that certificate is what stops someone in the middle.

More short lessons

ADIR also offers a free external pen test for cloud teams: see the offer.

Transcript

Once a TCP connection opens, TLS secures it. Here's how the handshake works, and which part stops an attacker in the middle. TLS runs on top of a reliable stream, typically TCP. It's designed to prevent eavesdropping, tampering, and forgery. That means three things. The server is authenticated. The data is visible only to the two endpoints. And it can't be changed without detection. The handshake is short. The client sends a ClientHello with its key share. The server answers with a ServerHello and its own key share. From there, everything is encrypted. The server sends its certificate, a signature, and a Finished message. The client confirms with its own Finished, and application data flows. Encryption alone isn't enough. The client must also validate the certificate: check its chain, and check that its name matches the server it meant to reach. Skip that, and an attacker in the middle can pose as the server. The connection then has no protection against them. So, TLS authenticates the server and protects the data. The handshake swaps key shares, then proves identity with a certificate. And validating that certificate is what stops someone in the middle.

Narrated with an AI voice.