[Ben Higgins <ben@xxxxxxxxxxxx>]

On Fri, May 18, 2018 at 6:02 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:

On 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:
>
>> 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.

pcapng_process_idb is called from pcapng_open only for IDBs at the *beginning* of the file.

There's no guarantee that IDBs won't appear after packet blocks; the only requirement in pcapng is that you can't have packets for a particular interface without the IDB for that interface having appeared.

So "[adjusting] pcapng_open and [adding] something similar to "pcapng_process_idb", but then for decryption blocks." would work for keylog blocks that appear at the beginning of the file, but it won't help with keylog blocks at the end of the file.

The *only* way to handle keylog blocks at the end of a file would be to make *two* passes over the file, with the first pass just reading blocks and *not* doing any dissection, and with all dissection done *after* all blocks have been read.  This would be a *significant* change to the way Wireshark works, and wouldn't work very well at all for one-pass TShark or live capture).

The same applies for any *other* program that would read pcapng files and do decryption.

So I would strongly advise doing whatever is necessary to put keylog blocks *before* any packet that requires them.

Roger that. Sounds like it'd still be fine for there to be multiple keylog blocks, but, as you say, they must occur before any packets that require the secrets contained therein. Is that correct?

 

___________________________________________________________________________
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