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

  1. Client Hello
  2. Server Hello
  3. Server Key Exchange
  4. Client Key Exchange
  5. Change Cipher Spec
  6. 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:


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.

SSL/TLS Handshake Explained

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.

SSL/TLS Handshake Explained

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.

server key exchange

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.

server key exchange

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?

  1. It generates a random session key (aka pre-master key).
  2. Encrypt the session key with the server’s public key.
  3. 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.

client key exchange

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


Go to Tools > Options > Advanced > Certificate > View Certificate.

firefox certificate manager


Go to settings > show advanced settings > manage certificate > authorities.

chrome certificate manager

Enable HTTPS on Your Web Server for Free

Rate this tutorial
[Total: 20 Average: 4.6]

12 Responses to “SSL/TLS Handshake Explained With Wireshark Screenshot (2022)

  • Thank you. That was very helpful!

  • Biman Chandra Roy
    5 years ago

    You wrote “pubkey is actually the session key”. Are you sure?

    • Xiao Guoan (Admin)
      2 years ago

      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.

      • Buggawa
        2 years ago

        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”.

  • João Campos
    4 years ago


    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

    • Xiao Guoan (Admin)
      2 years ago

      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.

  • Merkhabha
    1 year ago


    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 ?


    • Merkhabha
      1 year ago

      After double checking “EC Diffie-Hellman Server Params” are indeed encrypted with the host’s private key.


Leave a Comment

  • Comments with links are moderated by admin before published.
  • Your email address will not be published.
  • Use <pre> ... </pre> HTML tag to quote the output from your terminal/console.
  • Please use the community ( for questions unrelated to this article.
  • I don't have time to answer every question. Making a donation would incentivize me to spend more time answering questions.

The maximum upload file size: 2 MB. You can upload: image. Links to YouTube, Facebook, Twitter and other services inserted in the comment text will be automatically embedded. Drop file here