ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] Embed SSL keylog file in pcap-ng

From: Ben Higgins <ben@xxxxxxxxxxxx>
Date: Fri, 4 May 2018 09:33:39 -0700
On Fri, May 4, 2018 at 12:21 AM, Paul Zander <p.j.zander@xxxxxxxxxxx> 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@xxxxxxxxxxxxx
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@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