SSL/TLS Handshake Explained

 

An encrypted connection is established between the client and the server through a series of handshakes. This article covers the SSL/TLS handshake with wireshark.

1^st Step: Client Hello

The client starts the communication. The first step is called client hello. The client lists the versions of SSL/TLS and cipher suites it’s able to use.

2^nd Step: Server Hello

The server will see the list of SSL/TLS versions and cipher suites and pick the latest the server is able to use. Then the server sends a message to the client containing the SSL/TLS version and cipher suite that was selected.

3^rd Step: Server Key Exchange

After the server and client agree on the SSL/TLS version and cipher suite, then server sends two things. The first is its SSL/TLS certificate to the client. The client (web browser) validates the server’s certificate. Web browsers store a list of Root CA (Certificate Authority) in itself. These root CAs are third parties that are trusted by web browsers. The server’s certificate is issued by root CA or intermediate CA. Intermediate CA is a CA that is trusted by root CA.

Web browsers trust Root CA. Root CA trust intermediate CA. If the server’s certificate is issued by a trusted root CA or intermediate CA, then the browser trust the server’s certificate.

The second thing the server sends is its public key and signature. The public key is actually included in the certificate. The client and the server encrypt message with the public key and it can only be decrypted with the private key. The server never share its private key with anyone.

At the end of server key exchange, the server sends a server hello done message.

4^th Step: Client Key Exchange

Until now, all the information sent between the client and server is unencrypted. Now the client receives the server’s public key and generate a new session key (aka pre-master key) encrypted with the public key and sends it to the server. The session key can only be decrypted with the private key and because only the server has the private key so only the client and server know the session key. This session key is only valid in current session. The master Secret (pre-master key) is then used to generate the HMAC or MAC, which is the key used for hashing, and the write key, which is used for encryption.

5^th Step: Notify Cipher Spec

The change cipher spec message is sent by both the client and server to notify the receiving party that subsequent records will be protected under the just-negotiated Cipher Spec and keys.

6^th Step: Encrypted Handshake

The client and the server sends to each other an encrypted message saying the key information is correct.

Now the client (web browser) will see a green lock in the address bar. The client and server encrypt web traffic with the keys generated.