On Fri, May 4, 2018 at 1:15 AM, Peter Wu <pe...@lekensteyn.nl> wrote:
> Hi Ben, > > On Thu, May 03, 2018 at 04:13:33PM -0700, Ben Higgins wrote: > > 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 > > Looks like you have done your homework, that is pretty much the current > state :-) > > > 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. > > The TLS key log file is indeed sufficient for decryption. If people > still use RSA key files for some legacy configuration, then Wireshark > can currently already generate a key log file for you (File -> Export > SSL Session keys). > > At the moment I am not sure how the pcapng process works, but having a > specification would probably be nice for other interested parties. While > Wireshark supports multiple key log formats, I guess that those from > https://developer.mozilla.org/en-US/docs/Mozilla/Projects/ > NSS/Key_Log_Format > should be mentioned explicitly (except for RSA). All other formats might > work, but there will be no guarantees on the long term. > That's what I was thinking, rather than creating a new format for including TLS session secrets, we'd make use of the key log format as already specified. (Also, FWIW, I don't think there's necessarily any harm in including the RSA type, which doesn't actually include the private key, if Wireshark otherwise supports it, though it's not going to continue being relevant.) > The specification should also answer: > - Where in the pcapng file should the block be located? The information > must be available before the TLS dissector is invoked. > Great question. I don't know the details of how pcap-ng is processed by Wireshark (e.g. if, say, an index of blocks is created up-front or not), so I'll take a look and reply back next week. > - If it can be anywhere, can there be multiple blocks? > I don't think there'd be any harm in having multiple SSL/TLS session key log blocks; the contents of each could be merged into a single table, probably. > -- > Kind regards, > Peter Wu > https://lekensteyn.nl > ____________________________________________________________ > _______________ > 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
