Re: Embed SSL keylog file in pcap-ng

[Ben Higgins <ben () extrahop com>]

On Fri, May 4, 2018 at 12:21 AM, Paul Zander <p.j.zander () philips com> wrote:

> Hello,
>
>
>
> We are interested in storing the ZigBee network key in the pacpng file.
>
>
>
> Is it an option to define a new block type that can contain a key?
>
> Via fields in this block we can define for which protocol the key is.
>
> This is a generic solution that can purpose a lot of protocols.

I personally don't have a strong opinion on what would be better: multiple
block type at the pcap-ng level vs. a single pcap-ng block type with
subtypes (for e.g. SSL/TLS, ZigBee, etc).



> Regards,
>
> Paul Zander
>
>
>
>
>
> *From:* Wireshark-dev <wireshark-dev-bounces () wireshark org> *On Behalf Of
> *Ben Higgins
> *Sent:* vrijdag 4 mei 2018 01:14
> *To:* wireshark-dev () wireshark org
> *Subject:* [Wireshark-dev] Embed SSL keylog file in pcap-ng
>
>
>
> Hey,
>
>
>
> We're pretty interested in embedding SSL key log information into pcap-ng
> to make it really convenient to open up a single file and get SSL/TLS
> sessions decrypted.
>
>
>
> I looked around and found a ticket and some wiki content related to this
> subject:
>
>
>
> - "use capture file comment to configure SSL dissector" is at
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9616
>
> - https://wiki.wireshark.org/Development/PcapNg#Wishlist includes "SSL
> session keys" with a description and a link to the above ticket
>
> - and there's https://wiki.wireshark.org/DecryptionBlock -- what's
> described here is sounds really cool but in practice might be pretty tricky
> to implement
>
>
>
> What I'd like to do is instead create a new pcap-ng block type that we can
> put SSL keylog file contents into verbatim. Then we can leverage existing
> code in Wireshark for parsing keylog files. I'd also rather keep this
> scoped to keylog files and not private keys (since private keys are longer
> term secrets and are more sensitive to deal with and everything's heading
> toward PFS anyway).
>
>
>
> Any thoughts on this proposal? If folks are open to this approach then
> we'd be interested in writing up a patch.
>
>
>
> Thanks!
>
>
>
> Ben
>
>
>
> ------------------------------
> The information contained in this email may be confidential and/or legally
> protected under applicable law. The message is intended solely for the
> addressee(s). If you are not the intended recipient, you are hereby
> notified that any use, forwarding, dissemination, or reproduction of this
> email is strictly prohibited and may be unlawful. If you are not the
> intended recipient, please contact the sender by return e-mail and destroy
> all copies of the original email.
>
> ____________________________________________________________
> _______________
> 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-request () 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-request () wireshark org?subject=unsubscribe