Mastering Wireshark Network Analysis: Deep Dive into HTTPS Handshake and Packet Capture

Wireshark network analysis is like using a microscope for the network world, enabling us to see and understand everything happening within the network.

Last time, I shared how to capture HTTPS packets of QQ Music using Wireshark and discussed how to remove the encryption shell of HTTPS.

This time, let’s briefly talk about the handshake process of the HTTPS protocol, hoping everyone can gain some understanding for future reference.

This example is still based on capturing HTTPS packets of QQ Music using Wireshark.

As shown in the image above, the HTTPS handshake is built on the foundation of TCP, starting with a three-way TCP handshake (previously shared, feel free to check historical posts for a refresher), followed by establishing a TLS connection. Let’s focus on the TLS handshake process (HTTPS = HTTP + TLS/SSL).

We can use the “Statistics|Flow Graph” feature provided by Wireshark to display a flowchart of the HTTPS protocol handshake, as shown in the image below.

We can also use the “Display Filter” feature provided by Wireshark to filter out the key TLS handshake packets, as shown in the image below.

From the two screenshots above, we can outline several important steps of the HTTPS protocol handshake.

The HTTPS handshake process is very clear with the help of Wireshark. Next, we’ll analyze it layer by layer, like peeling an onion.

Through packet capture analysis with Wireshark, as shown in the image above, the Client Hello phase mainly involves the client informing the server of the TLS protocol version supported by the client, the encryption suites supported by the client, the compression methods supported by the client, and a random number generated by the client, among other related information.

Through packet capture analysis, as shown in the image above, the server determines the SSL/TLS protocol version to use based on the information supported by the client; determines which encryption suite and compression method to use; and generates a random number, Random.

This step mainly involves the server sending a certificate to the client.

This message involves the server sending parameters and data related to the key exchange algorithm to the client. Common key exchange algorithms include RSA, DH, ECDH, etc.

The server informs the client that the message has been sent.

This message is used to exchange key parameters, generate a pre-master key, and then transmit this key to the server. The server will use its private key to decrypt the key, obtain the third random number, and thus generate a communication key.

This message informs the server that future communications will be encrypted using the negotiated key.

The client generates a digest of the previous handshake messages and encrypts it with the negotiated key. If the server can decrypt it upon receipt, it indicates that the negotiated key is consistent.

Contains information needed for encrypted communication, encrypted with a key known only to the server. The goal is to eliminate the requirement for the server to maintain session state caches for each client.

This message informs the client that future communications will be encrypted using the negotiated key.

The server generates a digest of the handshake process messages and encrypts it with the key. This is the first encrypted message sent by the server. The client will decrypt it with the key upon receipt, and if it can be decrypted, it indicates that the negotiated key is consistent.

Next is data transmission. HTTPS data transmission is shown in the image below.

Learning from books is ultimately shallow; to truly understand, one must practice. Some areas that are not covered may require further analysis with Wireshark packet capture.

This concludes the Wireshark sharing for this time. To ensure no errors in the sharing, I consulted many documents, books, and official materials, summarized them for you, hoping it will be helpful.