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:
https://github.com/pcapng/pcapng/pull/54
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
https://code.wireshark.org/review/29901
Your feedback is welcome.
--
Kind regards,
Peter Wu
https://lekensteyn.nl
