Understanding the TLS handshake is essential for anyone interested in secure internet communication. The TLS handshake is a multi-phase protocol that establishes a secure session between a client (such as a browser) and a server. The process can be broken down into several distinct phases: client hello, server hello, certificate exchange, key agreement, and session establishment.

The handshake begins when the client sends a ClientHello message. This message includes supported TLS versions, a list of supported cipher suites, and a randomly generated value called the client random. The server responds with a ServerHello message, selecting the protocol version and cipher suite, and provides its own server random. The server then sends its digital certificate, which contains its public key and is signed by a trusted certificate authority. This certificate allows the client to authenticate the server's identity.

After the certificate exchange, the client verifies the server's certificate using the certificate authority's public key. If the certificate is valid, the client proceeds to the key agreement phase. Here, both parties agree on a shared secret, which is used to derive session keys. In modern TLS versions, this is often achieved using ephemeral Diffie-Hellman key exchange, which provides forward secrecy.

Once the key agreement is complete, both client and server use the shared secret to derive symmetric session keys. These keys are then used to encrypt and decrypt data during the session, ensuring confidentiality and integrity. The handshake concludes when both parties exchange Finished messages, indicating that the secure channel is established and ready for application data.

To better understand the flow of messages and state transitions during the TLS handshake, consider the following pseudo code representation:

Client: send ClientHello
Server: receive ClientHello
Server: send ServerHello
Server: send Certificate
Server: (optional) send ServerKeyExchange
Server: send ServerHelloDone
Client: receive ServerHello, Certificate, (ServerKeyExchange), ServerHelloDone
Client: verify Certificate
Client: generate PreMasterSecret
Client: send ClientKeyExchange
Client & Server: derive MasterSecret from PreMasterSecret, client random, server random
Client: send ChangeCipherSpec
Client: send Finished
Server: receive ChangeCipherSpec, Finished
Server: send ChangeCipherSpec
Server: send Finished
Client & Server: verify Finished
Session established, application data can be exchanged

Each message in this sequence plays a specific role in progressing the handshake and transitioning the session state from "not secure" to "secure."

Public key cryptography is at the heart of TLS authentication and key exchange. During the handshake, the server proves its identity by presenting a certificate containing its public key. The client uses this public key to verify the server's identity and to establish a shared secret without exposing it over the network.

Once authentication is complete, TLS uses a combination of asymmetric and symmetric cryptography. The initial key agreement (often Diffie-Hellman or ECDHE) allows both parties to compute a shared pre-master secret. This value is never sent directly; instead, both client and server generate it independently, ensuring that only they know the secret. From this pre-master secret, TLS derives symmetric session keys, which are used to efficiently encrypt and decrypt all subsequent data. This hybrid approach leverages the strengths of public key cryptography for secure key exchange and the performance of symmetric keys for bulk data encryption.

The process of deriving session keys and establishing a secure session in TLS can be summarized in the following pseudo code:

Inputs: PreMasterSecret, ClientRandom, ServerRandom

MasterSecret = PRF(PreMasterSecret, "master secret", ClientRandom + ServerRandom)

ClientWriteKey, ServerWriteKey, ClientWriteIV, ServerWriteIV = 
    PRF(MasterSecret, "key expansion", ServerRandom + ClientRandom)

Both client and server:
    - Use ClientWriteKey and ServerWriteKey for encryption and decryption.
    - Use ClientWriteIV and ServerWriteIV for initializing encryption algorithms.

After key derivation:
    - Both client and server send ChangeCipherSpec to switch to encrypted communication.
    - Both send Finished messages encrypted with session keys.

Session is now secured for application data transfer.

This process ensures that the actual session keys are never transmitted over the network, and are unique for every session.