On Fri, 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: > > 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@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