SSL/TLS Handshake Explained With Wireshark Screenshot (2022)
A TLS encrypted connection is established between the web browser (client) with the server through a series of handshakes. In this article, I will explain the SSL/TLS handshake with Wireshark.
HTTPS Connections Steps
- Client Hello
- Server Hello
- Server Key Exchange
- Client Key Exchange
- Change Cipher Spec
- Encrypted Handshake
Install Wireshark on Your Computer
You can use Wireshark to capture HTTPS connections.
Windows and macOS
Windows and macOS users can download Wireshark from the official website: https://www.wireshark.org/#download.
Linux
Linux users can install Wireshark from the default repository.
- Debian/Ubuntu: sudo apt install wireshark
- RHEL/CentOS/Fedora: sudo dnf install wireshark
- OpenSUSE: sudo zypper install wirshark
- Arch Linux: sudo pacman -S wireshark
If you are asked “Should non-superusers be able to capture packets?”, answer Yes. Once it’s installed, run the following command to add your user account to the wireshark group so that you can capture packets.
sudo adduser your-username wireshark
Log out and log back in for the changes to take effect.
Step 1: Client Hello
The client begins 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.
Step 2: Server Hello
The server will see the list of SSL/TLS versions and cipher suites and pick the newest the server is able to use. Then the server sends a message to the client containing the SSL/TLS version and cipher suite it chose.
Step 3: Server Key Exchange
After the server and client agree on the SSL/TLS version and cipher suite, the server sends two things.
- SSL/TLS certificate
- public key and signature
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 themselves. 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 trusts immediate CA. If the server’s certificate is issued by a trusted root CA or immediate CA, then the browser trust the server’s certificate. I will tell you how to find these root CAs in your web browser at the end of this article.
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 use the public key to encrypt messages, which can only be decrypted with the server’s private key. The server never shares its private key with anyone.
At the end of the server key exchange, the server sends a server hello done message.
Step 4: Client Key Exchange
Until now, all the information sent between the client and server is unencrypted. The client has the server’s public key, what will the client do now?
- It generates a random session key (aka pre-master key).
- Encrypt the session key with the server’s public key.
- Sends the encrypted session key to the server.
The encrypted session key can only be decrypted with the server’s private key. Only the server has the private key, so only the client and server can know the session key.
In Wireshark, you will see a pubkey in the client key exchange phase. This pubkey is actually the encrypted session key. It’s not the server’s public key.
Session key is only valid in one session. If the user closes the client and visits the same server the next day, a new session key will be generated by the client.
Step 5. Change 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 CipherSpec and keys.
Step 6. Encrypted Handshake
The client and the server send each other an encrypted message saying the key information is correct.
Now the client (web browser) will display a green lock in the address bar. The client and server encrypt HTTP traffic with the session key.
How to View Root CAs in Your Browser
Firefox
Go to Tools > Options > Advanced > Certificate > View Certificate.
Chrome
Go to settings > show advanced settings > manage certificate > authorities.
Enable HTTPS on Your Web Server for Free
- How to Properly Enable HTTPS on Nginx with Let’s Encrypt on Ubuntu Server
- How to Properly Enable HTTPS on Apache with Let’s Encrypt on Ubuntu Server
Thank you. That was very helpful!
You wrote “pubkey is actually the session key”. Are you sure?
I mean the pubkey in the Wireshark screenshot is the encrypted session key. It’s displayed as pubkey. It’s not the server’s public key.
Since the shown TLS-Handshake is using Diffie-Hellman, I would suggest, that this is the public-key which is created in the Diffie-Hellman procedure, then sent over to the server. Same goes for the server-side. Then both sides use their private keys to calculate the session-key.
Great article! one slight correction….”immediate CA” should instead be listed as “intermediate CA”.
Hello.
First all, thank you very much fort this. However I have a question, when I have a invalid certificate (its outdated, etc…), Or I dont have a
certificate. In which of the handshake steps the communication will be terminated ?
Thanks in advance and
best regards
If the server sends an invalid certificate, the handshake will be terminated at step 3.
Great article. Love the way you simplified the handshake.
Hello. my side have some problem.
the [ChangeCipherSpec] only happen at 1 side. server send [ChangeCipherSpec] to client. but client didnt send [ChangeCipherSpec] to server. and after that, server send FIN to client .
the https cant success on TLS handshake.
no too sure what can cause this in windows.
Hello,
”
Step 4: Client Key Exchange
This pubkey is actually the encrypted session key. It’s not the server’s public key.
”
I agree that it is not the public key of the server, i agree that it is signed, but i think it is not encrypted it would defeat the purpose of DH actually, what do you think ?
Regards
After double checking “EC Diffie-Hellman Server Params” are indeed encrypted with the host’s private key.
Regards