[Ben Higgins <ben@xxxxxxxxxxxx>]

On Fri, May 18, 2018 at 7:49 PM, Jim Young <jim.young.ws@xxxxxxxxx> wrote:

Hello Ben,

Similar to the way that IDBs must be preceded by any EPBs that reference it, Apple's tcpdump can augment pcpang files with proprietary process information blocks.  EPBs are augmented with proprietary options that can reference any preceding process information blocks.

Unfortunately Apple in their infinite wisdom opted not to register reserved values for their packet information blocktype number nor for the various process information related EPB option numbers.  Instead Apple opted to go the lazy route and simply used "local use" values.

Please do not Apple's mistake of using "local use" values in pcapng capture files that will be publicly available.

Late last year I submitted a hacky and currently stalled WIP attempt to process these proprietary Apple blocks and options in change 24641. The fact that Apple used "local use" values (and choose specific "local use" values that arguably are more likely to be used by others) it is not likely my patch or anything better will be merged unless parsing and processing of the Apple propriety block and options pcapng are optional and disabled by default.

I'll be looking forward to seeing how you implement the SSL keylog info into pcapng.

Thanks for the background, Jim.

I don't think it makes sense for there to be anything proprietary in this block. The contents of this block will be what Wireshark already supports for key log files, described here: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format

The big win is that a single pcapng file can contain everything needed for Wireshark to decrypt its contents. Today, the user has to jump through some hoops (either clicking through dialog boxes or knowing the (perhaps undocumented?) command-line option) to select a keylog file. We want to improve on that experience.

Ben

Good luck and best regards,

Jim Y.

On Fri, May 18, 2018 at 10:05 PM, Ben Higgins <ben@xxxxxxxxxxxx> wrote:

On Friday, May 18, 2018, Guy Harris <guy@xxxxxxxxxxxx> wrote:

On May 18, 2018, at 6:08 PM, Ben Higgins <ben@xxxxxxxxxxxx> wrote:

> Sounds like it'd still be fine for there to be multiple keylog blocks,

Yes.

> but, as you say, they must occur before any packets that require the secrets contained therein. Is that correct?

Yes.

Great, thanks. I plan to have us implement this feature accordingly. Should we file a new ticket along these lines or will the existing ticket suffice?

___________________________________________________________________________
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

___________________________________________________________________________
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

___________________________________________________________________________
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