Decoding TLS 1.3 Protocol Handshake With Wireshark

TLS 1.3 the most latest version of TLS protocol is now two years old. But, many people don’t know much about it. It’s worth understanding the new TLS 1.3 protocol as TLS has seen a significant change in version 1.3 compared to its predecessors. Decoding TLS 1.3 protocol handshake is not as simple as decoding TLS 1.2. Because most of the handshake process is encrypted in this revision. So tcpdump is not enough to examine the TLS 1.3 protocol handshake. In TLS 1.3 everything after the server hello packet is encrypted including certificate exchange. We can’t use tcpdump to see the message exchange. We should require programs like OpenSSL or Wireshark to decode TLS 1.3 protocol handshake process.There are two main factors that made this version superior:r:

TCP Three-Way Handshake Protocol:

In HTTPS, a TLS handshake will happen after the completion of a successful TCP handshake. TCP handshake process is a separate topic, so we are not covering that in this article. To tell in short, TCP handshake is a three-step process. First, the client sends the SYN packet to the server. Second, the server sends SYN + ACK in response to the client. At last, the client sends the acknowledgment to the server.

192.168.0.114 is the client machine. 54.192.148.64 is the destination amaxon.com.

TLS Handshake Protocol:

TLS handshake will kick off imminently after the TCP three-way handshake process gets completed..

Step #1: Client Hello

The TLS 1.3 handshake also begins with the “Client Hello” message as in the case of TLS 1.2. So far, this doesn’t look surprising,See the next information. Now, it’s unexpected to see the client is requesting a TLS 1.2 handshake. In fact, it is. The reason for this is, practically, TLS 1.3 isn’t as close to the universe as TLS 1.2. Most of the web servers still try to negotiate TLS 1.2. And, in support of this, there is no much difference in the Client Hello message of TLS 1.2 and 1.3. If the server only understands TLS 1.2, it will just negotiate a TLS 1.2 handshake as before. If so, then how does the client tells the server that it actually understands TLS 1.3 too? Well, the answer is a new client hello extension.

The Client of course sends the list of supported cipher suites, supported TLS version, UTC time, 28-byte random number, session ID, URL of the server, and guesses which key agreement protocol the Server is likely to select. The Client also sends its key share for that particular key agreement protocol.

Step #2: Server Hello, Change Cipher Spec, Server Finished, and Encrypted Application Data

In reply to the “Client Hello” message, the server replies with the ‘Server Hello’ and the chosen key agreement protocol if it supports TLS 1.3. The ‘Server Hello’ message not only contains the session ID, UTC time, 28-byte random number, and selected cipher suite but also the Server’s key share, its certificate, and the ‘Server Finished’ message and starts encrypting the data. From this message, the server will send the data in encryption format.

In TLS 1.2 handshake process server sends a finished message and starts encrypting the data in the second round trip in step 5.

Step #3: Change Cipher Spec, Client Finished, and Encrypted Application data

Now, the Client checks the certificate shared by the Server, generates symmetric keys as it has the key share of the Server, and sends the ‘Change Cipher Spec and’ and ‘Client Finished’ messages. From this point, both the Client and the Server start communicating by encrypting messages.

In TLS v1.3, the whole process is shortened from six steps to three steps. This saves approximately 25% to 50% of the time to complete the TLS process. This completes the TLS 1.3 protocol handshake process.

Thanks for reading this article. Please visit our site to read such interesting articles..