ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Wireshark-dev: [Wireshark-dev] Proposal for storing decryption secrets in a pcapng block

From: Peter Wu <peter@xxxxxxxxxxxxx>
Date: Sun, 30 Sep 2018 19:47:07 +0200
Hi all,

Earlier this year, Ben Higgins proposed a new pcapng block to store
SSL/TLS session secrets that would allow users to enable decryption of
packet traces without further configuration. I would like to solicit for
some feedback on this proposed specification update:

Among the open spec issues:
- Are you happy with the chosen identifiers (10 for block type and
  0x544c534b ("TLSK") for the TLS key log secret type).
- Rename the block from the original proposal (it seems based on "IDB",
  but "Decryption Secrets Block (DSB)" sounds better to me).
- Is there a use case for multiple secret blocks?
- For multiple secret blocks, is concatenation a good merge strategy?
- Is this format future-proof and usable for other formats like ZigBee?

Advantages of allowing multiple blocks:
- Producers can write secrets directly while writing packets.
- Merging multiple capture files is simpler.

Requirements for block placement:
- No requirement. Producers are allowed to write the block anywhere.
  Disadvantages for consumers: requires a two-pass scan to collect
  secrets before they are used.
- Place secrets before the packet blocks that require them. Consumers
  can read and decrypt in one pass. Disadvantage: producers cannot
  always guarantee availability of secrets while writing the capture.
- Place a single secret block before the first packet block. Consumers
  can read and decrypt in one pass. Disadvantage: requires producers to
  post-process (rewrite) the capture file to insert secrets.

As these blocks contain sensitive (session) secrets, they should be
carefully handled, but that's probably a different discussion. The
current Wireshark patches that implement *read-only* support is at

Your feedback is welcome.
Kind regards,
Peter Wu