On Fri, May 18, 2018 at 6:02 PM, Guy Harris <g...@alum.mit.edu> wrote:
> On May 18, 2018, at 5:51 PM, Peter Wu <pe...@lekensteyn.nl> 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@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject= > unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
