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).
Both these sound good to me.
- Is there a use case for multiple secret blocks?
Certainly if you have different secret block types (so you might need one of each). Even for the same type it'd make it easier on producers that might not know the length of all secrets up front (i.e. it's filling up a buffer as it goes and spitting out a secret block once the buffer's full).
- For multiple secret blocks, is concatenation a good merge strategy?
Concatenation should work fine among TLSK blocks assuming all blocks have a final newline (or one is inserted if missing during concat; perhaps that needs to be specified).
- Is this format future-proof and usable for other formats like ZigBee?
Not sure if the merge strategy could be uniform among other secret formats, but otherwise this spec seems future-proof since a new secret type can entail a new secret format.
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.
I'm fine with the second option given that, as you note, "No requirement" is more challenging on consumers.
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
_______________________________________________
pcap-ng-format mailing list
pcap-ng-format@xxxxxxxxxxx
https://www.winpcap.org/mailman/listinfo/pcap-ng-format
