The Cryptography Inside TLS: Handshake, Keys, and Cipher Suites (2026)

TLS, despite its ubiquity, fundamentally relies on the fact that public key cryptography is computationally expensive, forcing a clever hybrid approach.

Let’s watch a TLS handshake unfold in real-time. Imagine a client (client.example.com) trying to connect to a server (server.example.com) on port 443.

CLIENT -> SERVER: ClientHello
  Protocol versions: TLS 1.2, TLS 1.3
  Cipher Suites: TLS_AES_128_GCM_SHA256, ECDHE-RSA-AES128-GCM-SHA256, ...
  Random: 32 bytes of client random data

SERVER -> CLIENT: ServerHello
  Chosen Protocol Version: TLS 1.3
  Chosen Cipher Suite: TLS_AES_128_GCM_SHA256
  Random: 32 bytes of server random data

SERVER -> CLIENT: Certificate
  Server's public key certificate (signed by a CA)

SERVER -> CLIENT: CertificateRequest (optional, for client authentication)

SERVER -> CLIENT: ServerKeyExchange (optional, if needed for key exchange)

CLIENT -> SERVER: Certificate (optional, if server requested it)

CLIENT -> SERVER: ClientKeyExchange
  (Here, the client encrypts a pre-master secret with the server's public key from the certificate)

CLIENT -> SERVER: ChangeCipherSpec (indicates encryption is now active)
  (Client and Server derive session keys from the pre-master secret and randoms)

SERVER -> CLIENT: ChangeCipherSpec (indicates encryption is now active)

CLIENT -> SERVER: Finished (encrypted, verifying handshake integrity)

SERVER -> CLIENT: Finished (encrypted, verifying handshake integrity)

This Finished message is crucial. It’s the first encrypted message, and its successful decryption and validation by both sides confirm that the handshake completed correctly and that no one eavesdropped or tampered with the negotiation.

The core problem TLS solves is enabling two parties to communicate securely over an untrusted network. This requires two main things: authentication (proving who you are talking to) and confidentiality/integrity (ensuring messages are secret and haven’t been altered).

Public key cryptography (like RSA or Elliptic Curve Diffie-Hellman) is used for the initial handshake to establish a shared secret, but it’s too slow for encrypting all the application data. Symmetric encryption (like AES) is much faster but requires both parties to have the same secret key beforehand. TLS cleverly bridges this gap.

1. Key Exchange: The handshake starts with a ClientHello and ServerHello to agree on the TLS version and cipher suite. Then, a key exchange mechanism (like Diffie-Hellman) is used to generate a shared secret without ever sending it over the wire. For example, in an ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) exchange, both client and server generate temporary key pairs. They exchange their public keys, and using their own private key and the other party’s public key, they can both independently compute the same shared secret. The server’s certificate is used to authenticate its public key during this process, preventing Man-in-the-Middle attacks.

2. Session Key Derivation: The shared secret generated during the key exchange is combined with the client random and server random values (sent in the ClientHello and ServerHello) through a pseudorandom function (PRF) to create the actual symmetric encryption keys (session keys) used for the rest of the connection. These keys are unique to each session.

3. Cipher Suites: A cipher suite is a named combination of algorithms that the client and server agree upon. It specifies:

   • The key exchange algorithm (e.g., ECDHE, RSA).
   • The authentication algorithm (e.g., RSA, ECDSA).
   • The bulk encryption algorithm (e.g., AES-128-GCM, CHACHA20-POLY1305).
   • The message authentication code (MAC) algorithm (e.g., SHA256, SHA384). In TLS 1.3, the cipher suites are simpler and focus on AEAD (Authenticated Encryption with Associated Data) ciphers like AES_128_GCM_SHA256 which combine encryption and integrity.

The most surprising aspect of TLS is how the server’s identity is verified. It’s not by directly checking if the server is "who it says it is" but by verifying a chain of trust. The server presents a certificate issued by a Certificate Authority (CA). Your browser (or operating system) has a pre-installed list of trusted CA root certificates. It checks if the server’s certificate was signed by a CA that is in its trusted list, or by a CA that was itself signed by a trusted CA, and so on, up to a root. If this chain of trust is valid, the server’s identity is considered verified, even though your client has never directly communicated with the entity you believe the server to be.

The next step is understanding how application data is encrypted and protected using the derived session keys, and the role of the TLS record protocol.