What is a TLS handshake? How secure connections are established

A TLS handshake is the negotiation that happens at the start of a secure connection, during which the client and server agree on a protocol version and cipher suite, the server proves its identity with a certificate, and both sides securely establish the shared keys that will encrypt the rest of the session. It is the step that turns an ordinary TCP connection into an authenticated, encrypted channel, and it is the foundation of HTTPS and most secure internet communication.

Key takeaways

• The TLS handshake authenticates the server, negotiates parameters, and establishes shared encryption keys.
• It uses asymmetric cryptography to bootstrap trust, then the session uses fast symmetric encryption.
• TLS 1.3 streamlined the handshake to one round trip and removed legacy insecure options.
• Certificates and the chain of trust let the client verify it is talking to the real server.
• Ephemeral key exchange provides forward secrecy, protecting past sessions if a key later leaks.
• Most handshake failures trace back to certificate, version, or clock problems.

What is a TLS handshake?

TLS, Transport Layer Security, is the protocol that secures data in transit for HTTPS and many other services. Before any application data flows, the two parties must agree on how to protect it. That agreement is the handshake.

The handshake accomplishes three things at once: it lets both sides settle on a mutually supported TLS version and cipher suite, it authenticates the server so the client knows it is not talking to an impostor, and it derives the symmetric keys used to encrypt and integrity-protect the session. It combines asymmetric cryptography, used to authenticate and agree on a secret, with symmetric cryptography, used afterward for speed. Once the handshake finishes, the encrypted session begins.

What happens during a TLS 1.2 handshake?

The traditional TLS 1.2 handshake takes two round trips and proceeds roughly as follows:

1. The client sends a ClientHello listing supported TLS versions, cipher suites, and a random value.
2. The server replies with a ServerHello choosing the version and cipher suite, its own random value, and its certificate.
3. Depending on the cipher suite, the server and client exchange key-agreement parameters, for example ephemeral Diffie-Hellman values.
4. Both sides use the exchanged material and the random values to derive the same shared secret and session keys.
5. Each side sends a Finished message, encrypted with the new keys, verifying the handshake was not tampered with.

After this, application data flows encrypted. The extra round trip is one reason TLS 1.2 connections have slightly higher setup latency than TLS 1.3.

How is the TLS 1.3 handshake different and faster?

TLS 1.3 redesigned the handshake for both speed and security. The most visible change is that it completes in a single round trip, often described as 1-RTT. The client optimistically sends its key-share in the ClientHello, so the server can immediately respond with everything needed to start encrypting.

TLS 1.3 also removed a large amount of legacy baggage. Outdated and insecure key-exchange methods, weak ciphers, and problematic features were dropped, leaving a smaller set of strong, modern options. It always uses ephemeral key exchange, so every TLS 1.3 connection gets forward secrecy by default. There is an optional 0-RTT mode that can send data on resumption with zero round trips, but it carries replay risks and must be used carefully for non-idempotent requests. Overall, TLS 1.3 handshakes are faster and safer by construction.

What is the role of certificates and the chain of trust?

Authentication is what stops an attacker from impersonating a server. During the handshake, the server presents an X.509 certificate that binds its identity, such as a domain name, to a public key, signed by a certificate authority (CA).

The client validates this by walking the chain of trust:

• The server’s certificate is signed by an intermediate CA.
• The intermediate is signed by a root CA.
• The root is one the client already trusts, held in its trust store.

The client checks that the chain is complete and valid, that the certificate is not expired, that the name matches the host it intended to reach, and that the certificate has not been revoked. Only if all checks pass does it trust the server’s key. This is why a misconfigured or expired certificate breaks the handshake entirely.

What is forward secrecy and how does the handshake provide it?

Forward secrecy means that even if an attacker later obtains the server’s long-term private key, they still cannot decrypt previously recorded sessions. This matters because encrypted traffic can be captured and stored, then decrypted later if a key is compromised.

The handshake achieves forward secrecy through ephemeral key exchange, typically ephemeral Diffie-Hellman or its elliptic-curve variant. For each session, both sides generate fresh, temporary key-exchange values, derive a shared secret from them, and then discard the temporary private values. The long-term certificate key is used only to authenticate the exchange, not to derive the session secret. Because the ephemeral values are thrown away, there is nothing left for a future attacker to use to reconstruct old session keys. TLS 1.3 makes this behavior mandatory.

What are cipher suites?

A cipher suite is the bundle of algorithms the connection agrees to use. In TLS 1.2 a suite names several components at once: the key-exchange method, the authentication method, the symmetric cipher for bulk encryption, and the integrity or hash function. An example combination is ephemeral elliptic-curve Diffie-Hellman for key exchange, RSA or ECDSA for authentication, and AES-GCM for authenticated encryption.

TLS 1.3 simplified this. Its cipher suites specify only the symmetric encryption and hash, because key exchange and authentication are negotiated separately and are always based on modern, secure mechanisms. In both versions, the negotiation ensures both parties end up using a set of algorithms they mutually support, and the server generally selects from the client’s offered list, ideally preferring the strongest available option.

What are common TLS handshake errors and pitfalls?

• Expired certificate. A certificate past its validity date fails validation and aborts the handshake.
• Name mismatch. The certificate must cover the hostname being requested, or the client rejects it.
• Incomplete chain. If the server does not send the necessary intermediate certificates, some clients cannot build a path to a trusted root.
• Clock skew. A wrong client clock can make a valid certificate appear expired or not yet valid.
• Protocol or cipher mismatch. If the client and server share no common supported version or suite, the handshake cannot proceed.
• Outdated configuration. Supporting only obsolete protocol versions is both a compatibility and a security problem; keep configurations current.

How can you inspect a TLS handshake?

You can examine a handshake directly with command-line tooling, which is invaluable for debugging. A common approach uses OpenSSL:

openssl s_client -connect example.com:443 -servername example.com

This connects to the host, performs the handshake, and prints the negotiated protocol version and cipher, along with the certificate chain the server presented. The -servername flag sends the Server Name Indication, which is important because many servers host multiple sites on one address and select the certificate based on it. Reviewing this output lets you confirm the version, verify the chain is complete, check expiry dates, and diagnose exactly where a failing handshake goes wrong.

Frequently asked questions

What is the purpose of a TLS handshake?

It authenticates the server (and optionally the client), negotiates the protocol version and cipher suite, and securely establishes the shared keys used to encrypt the session.

How is the TLS 1.3 handshake different from 1.2?

TLS 1.3 is faster, completing in one round trip, removes outdated and insecure options, and always uses ephemeral key exchange for forward secrecy.

What is forward secrecy?

It means that compromising a server’s long-term private key later cannot decrypt past sessions, because each session uses fresh ephemeral keys that are discarded.

What role do certificates play in the handshake?

The server presents a certificate chain proving its identity, which the client validates against trusted certificate authorities to prevent impersonation.

What is a cipher suite?

It is the negotiated set of algorithms used for key exchange, authentication, bulk encryption, and integrity for the connection.

Why does a handshake fail with a certificate error?

Common causes include an expired certificate, a name mismatch, an untrusted or incomplete chain, or a clock skew on the client that makes a valid certificate appear expired.

Can I inspect a TLS handshake myself?

Yes. Tools like openssl s_client let you connect to a host, view the negotiated version and cipher, and inspect the presented certificate chain.