Wireshark-dev: Re: [Wireshark-dev] Embed SSL keylog file in pcap-ng
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Ben Higgins <ben@xxxxxxxxxxxx>
Date: Fri, 18 May 2018 18:06:24 -0700


On Fri, May 18, 2018 at 5:51 PM, Peter Wu <peter@xxxxxxxxxxxxx> wrote:
On Fri, May 18, 2018 at 11:44:12AM -0700, Ben Higgins wrote:
> Hey folks,
>
> Here's what I'm thinking at this point: a new block type for SSL/TLS
> keylogs and another block type for DTLS keylogs. The contents of each will
> be the format as described here:
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format

The key log file format is the same for TLS and DTLS, but due to an
implementation detail (two separate preferences for DTLS and TLS in
Wireshark), they are different. I am not opposed to having two different
blocks, but would it make more sense to combine them and create a single
"TLS key log" block and have both the DTLS and TLS dissectors read it?

Yes, I think having one block would make more sense.

The only reason I proposed two was because I noticed this Wireshark implementation detail :-)
 
> Any number of these blocks can be included. For each block encountered,
> ssl_load_keyfile will be called, with the correct per-protocol master key
> map included. Some code refactoring to ssl_load_keyfile will likely be
> required since we're dealing with an array of bytes instead of a FILE.

Ok, doable.

> One thing I'm unclear on is how to trigger a reparse of previously
> processed packets when a keylog block is encountered at e.g. the end of the
> file. Is that possible?

Decryption currently requires keys to be available on the first pass.
I guess that for offline capture files, one needs to adjust pcapng_open
and add something similar to "pcapng_process_idb", but then for
decryption blocks.

Kinds regards,
Peter
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@wireshark.org?subject=unsubscribe