In the last part of this two-part blog on Wireshark v3, we covered the following topics:
Translations
Npcap (No More WinPcap)
UDP Conversation Timestamping
Tshark and ElasticSearch
Capture Information is Back
Checksum Validation Disabling
String() Display Filter Function
DHCP and TLS
Let’s look at a few more features that have been updated or added to Wireshark v3.
If you aren’t one of my “In Laura’s Lab” Newsletter subscribers, please visit sign up so I can let you know when new blogs, videos, training classes, books, and challenges are released. Many things are changing in 2019 and I am thrilled to be able to return to projects that allow me to share my passion of analysis with all of you!
As I mentioned in Part 1, Wireshark v3 offers some significant and exciting changes that I think the Wireshark community will appreciate. Let’s go! Here is the second set of updated/new features in Wireshark v3!
Dumpcap packet enhancement
“No Reassembly” profile
Out-of-order segment reassembly TCP preference
Custom window title
Decryption Secrets Block (DSB) - embed a session key in a trace file
Remember, sign up for the Newsletter to receive notices when new blogs are released.
Dumpcap Packet Enhancement
Dumpcap now supports the -a packets:NUM and -b packets:NUM options.
The -a parameter defines an autostop condition. The -b parameter calls the ring buffer feature.
Although Dumpcap has always supported the -a and -b parameters, it didn’t support the packets option. Previously, you could only define autostop or ring buffer conditions based on duration, file size, or number of files.
The following Dumpcap command uses the new parameter options:
dumpcap -i3 -a packets:300 -b packets:100 -w 100pktsets.pcapng
This command implements the following settings:
-i3 capture on interface number 3
-a packets:300 stop after capturing a total of 300 packets
-b packets:100 capture 100 packets per file in a file set
-w 100pktsets.pcapng write to a file set that begins with 100pktsets
Before the release of Wireshark v3, you would need to use Tshark for these capabilities. Remember that Tshark actually calls Dumpcap to perform the capture process. If you don’t need any of the other features that are unique to Tshark, you can use Dumpcap.
“No Reassembly” Profile
Wireshark now includes a “No Reassembly” configuration profile. If you’ve ever seen me teach Wireshark classes, you know that I spend a fair amount of time talking about the difference in analyzing traffic with TCP reassembly on and off. Wireshark enables TCP reassembly by default. For example, when you download a file from a web server, if that file is too large to fit in a single TCP packet, Wireshark will reassemble all the packets of the file and place the reassembled contents on the last packet of the file download set.
Unfortunately, Wireshark will also set application response times based on that last packet, rather than the first response packet from the server. To measure the response time, I must turn off TCP reassembly.
Out-of-order segment reassembly TCP Preference
The TCP dissector gained a new Reassemble out-of-order segments preference to fix dissection, decryption, and object export issues when TCP segments are received out-of-order.
Let’s take a look at an example. In the http-espn-b.pcapng trace file (available at https://www.chappell-university.com/traces), the Expert Information window indicates there are four out-of-order packet is the trace file. Two packets are SYN/ACK packets and two packets are HTTP 200 OK packets. This new feature won’t do anything for our SYN/ACK packets, but it will enable us to reassemble the objects downloaded after the HTTP 200 OK packets.
Out-of-order segment reassembly TCP Preference=Off
When this setting is disabled (the default setting), out-of-order packets prevent Wireshark from reassembling objects for export.
Out-of-order segment reassembly TCP Preference=On
When this setting is enabled, packets are automatically reassembled so that you can export the objects.
In the example below, you can see how this preference setting affects the File | Export objects function.
This setting should be enabled if you are using TCP reassembly with the Allow subdissector to reassemble TCP streams preference setting.
Custom Window Title
The custom window title can now show the file path of the capture file, the current profile name, and version number. To set a new window title, select Edit | Preferences | Advanced and search for “window title”. The preference setting you are looking for is called gui.window_title.
%F = file path of the capture file
%P = profile name
%S = conditional separator (“-”) that only shows when surrounded by variables with values or static text
%V = version information
See the example below:
This may seem like a minor addition to Wireshark, but recently my editor, Jim Aragon, was working with multiple trace files I had sent him over time which (strangely) had the same file name, but contained a different number of packets. Jim saved each file into a separate directory and, by customizing the window title, he could easily tell which file he was working on. It’s a nice feature to have when you need it.
Embed a Session Key in a Trace File
As you may already know, you can decrypt a trace file containing encrypted communications if you have the RSA key used by the server in the trace file. By adding the RSA key in Edit | Preferences | RSA Keys, as shown in the following image.
If you want to share the unencrypted file, however, you certainly don’t want to share your RSA key! That is why Wireshark enables you to export the TLS session key using File | Export TLS Session Keys.
When you share an encrypted trace file and provide someone with the session key, they can configure Wireshark to use that key in Edit | Preferences | TLS | (Pre)-Master-Secret log filename, as shown below.
In 2018, it was suggested that the .pcapng trace file format be enhanced with a new block to store SSL/TLS session secrets that would allow users to decrypt trace files without further configuration.
To follow the first conversations discussing this new feature as it was developed, visit
The change is in the .pcapng trace file format and Editcap. Editcap now includes a --inject-secrets parameter.
The syntax is editcap --inject-secrets <protocol>,<session.key> <encryptedfile.pcapng> <unencryptedfile.pcapng>
Hand off the unencryptedfile.pcapng to someone and they can open the unencrypted file in Wireshark without dealing with the session key or Wireshark configurations!
You can read the Decryption Secrets Block (DSB) details in Section 4.8 of the PCAP Next Generation (pcapng) Capture File Format at https://github.com/pcapng/pcapng.
Try It Yourself!
Step 1:
Download rsasnakeoil2.pcapng and rsasnakeoil2.key from https://www.chappell-university.com/traces. Create a directory called /keyembed on your system and place both files in this directory.
Step 2:
Open rsasnakeoil2.pcapng in Wireshark v3. Select Edit | Preferences | RSA Keys.
Step 3:
Let's decrypt the file. Click Add new keyfile… and select rsasnakeoil2.key from your /keyembed directory. Click Open. Click OK to close the Preferences window. You may need to click the Reload button on the main toolbar to see the decrypted traffic. You should now see some packets colored green by the HTTP coloring rule.
Step 4:
Next, we want to export the session key. Select File | Export TLS Session Keys… and save your key (name it rsasession.key) into your /keyembed directory.
Step 5:
We want to remove the RSA key now. Return to Edit | Preferences | RSA Keys, click on your key listed and select Remove Key. Click OK.
Step 6:
[Ensure you have the Wireshark program directory in your path.] At the command prompt, navigate to your /keyembed directory.
Type the following command (disregard the carriage return required by this blog's formatting):
editcap --inject-secrets tls,rsasession.key rsasnakeoil2.pcapng snakeoil-withkey.pcapng
Step 7:
Open your snakeoil-withkey.pcapng file in Wireshark. You will see the trace file unencrypted without use of the public RSA key.
Nice, eh?
What Are You Waiting For?
Some of you may be hesitant to jump to Wireshark v3, but just go for it. It’s not such a huge difference that you can’t hit the ground running and the bug list is relatively small at this point. The added features are worth the upgrade process.
Thanks to Gerald Combs and the Wireshark developers who have contributed to Wireshark v3. All of us in the Wireshark community appreciate your efforts.