0 / 9
TLS 1.2 Handshake
TLS (Transport Layer Security) lets two parties that have just met, such as a browser and a web server, communicate securely. Before any data moves, the two sides first run a message exchange called the handshake. In it they agree on how to encrypt, the server proves it is genuine, and they create a key to share. This diagram shows that order for TLS 1.2. It comes down to four stages: negotiation, server authentication, key exchange, and final check. Once the handshake ends, encrypted communication begins.
Example: a browser (Client) connects to a shopping site's web server (Server) for the first time.
1 / 9
Client → Server: ClientHello
The Client speaks first. It sends the highest TLS version it supports, the cipher suites it can use, and a random value, Client Random. The random value is not a secret; it travels as is and makes the keys different for each connection. A cipher suite bundles the algorithms for key exchange, authentication, and encryption into one set.
2 / 9
Server → Client: ServerHello
The Server picks one cipher suite that both sides can use from the Client's list and settles on a TLS version. It also sends its own random value, Server Random. Negotiation ends here.
3 / 9
Server → Client: Certificate
The Server sends its certificate. The certificate holds the Server's public key and a signature from a certificate authority (CA) saying the key belongs to that domain. It also sends ServerHelloDone to signal that the hello phase ends here.
4 / 9
Client: verify the certificate
The Client checks the certificate itself. It follows the certificate's signature through any intermediate CA up to a root CA already built into the browser, and checks that the signature is valid, that the certificate has not expired, and that its domain matches the site being visited. It can also use CRL or OCSP to check that the certificate has not been revoked. If any check fails, it shows a warning or stops the connection. If all pass, it trusts that the public key belongs to the real Server.
5 / 9
Client → Server: ClientKeyExchange
The Client creates a secret value, the premaster secret, which will be the raw material for the session key (a symmetric key used only for this connection). It encrypts this value with the Server's public key and sends it. Even if someone intercepts it, they cannot decrypt it without the Server's private key.
6 / 9
Client and Server: compute the session key
The Server decrypts the premaster secret with its private key. Now both sides hold Client Random, Server Random, and the premaster secret. Each runs the same calculation. The three values produce a master secret, and the keys actually used for encryption are taken from it. So both sides end up with the same session key, and the session key itself is never sent over the network.
7 / 9
Client → Server: ChangeCipherSpec, Finished
The Client sends ChangeCipherSpec to say that from now on it will encrypt with the session key. Right after, it sends Finished. Finished carries a check value over all the handshake messages exchanged so far, and it is the first message encrypted with the session key.
8 / 9
Server → Client: ChangeCipherSpec, Finished
The Server sends ChangeCipherSpec and Finished the same way. If the check value the Client received matches the one it computed itself, nothing in the negotiation was altered on the way and both hold the same session key. Making a correct Finished requires decrypting the premaster secret, so it also confirms the real Server with the private key. If they do not match, the connection is dropped.
9 / 9
Encrypted communication begins
The handshake is over. From now on, the data that flows (Application Data) is encrypted with the session key. It uses the same key to encrypt and decrypt, a symmetric method, so it is fast. Slow public-key cryptography is not used for the data; it only helps settle the key.