On Thu, Apr 06, 2017 at 02:41:15PM +0200, Bogdan Pavkovic wrote:
> Hi Peter, all,
>
> Thanks a lot for the insight regarding this patch.
> I will look into details regarding the separate keylog file according to
> SSL/TLS example.
>
> One question nevertheless:
> is there a particular need to write Lua post-disector script
> instead of updating the keylog directly from the dissector?
It could also be done from the dissector, but it feels a bit strange to
write to an input file (keylog file) which is supposed to provide keys.
A possible alternative is to create a second preference, pointing to the
file where new keys are appended. Yet another option is a boolean
preference, controlling whether new keys are allowed to be written to
the "input" keylog file. Then the user can control whether it is OK to
write the file.
Peter
> Best regards,
> Bogdan
>
> *From*: Peter Wu <peter@xxxxxxxxxxxxx <[email protected]>>
> > *Date*: Fri, 24 Mar 2017 12:28:06 +0100
> >
> > On Tue, Mar 21, 2017 at 05:07:28PM -0400, Michael Mann wrote:
> > > There are currently two outstanding patches
> > > (https://code.wireshark.org/review/20585 and
> > > https://code.wireshark.org/review/20656) that want to modify a UAT at
> > > runtime for additional decryption keys/information found during
> > > dissection. In this case the UAT is providing all of the "static"
> > > keys, but apparently these dissectors can have some at runtime too.
> > > Are there currently dissectors that handle such a case so these
> > > patches can be modeled after those?
> >
> > The problem with the ZigBee dissector (20656) appears as follows:
> >
> > - There is a static (master?) key, configured in UAT.
> > - Session keys are encrypted by the master key and transmitted through
> > a special message.
> > - When a capture is split, this special message will only appear in the
> > first capture file and not in the succeeding files. Since the session
> > key is not known, these other files cannot be decrypted (only the
> > first one can be decrypted).
> >
> > This (unhandled) result is comparable to the SSL/TLS dissector, if the
> > TLS handshake messages are missing, the following application data
> > cannot be decrypted.
> >
> > > The only solution I can think of is to have a copy of the UAT taken
> > > (created in the post_update callback of the UAT) and then add the
> > > "runtime" decryption keys to the copy. Not the prettiest so I thought
> > > I'd elicit other opinions.
> >
> > The UAT was designed to give the GUI full control over the contents, the
> > dissectors only get a copy of it. Trying to change this might be
> > difficult. Adding the "runtime" (session) keys to the copy will not help
> > if the capture file is changed and the UAT is reloaded.
> >
> > As for how dissectors handle decryption keys, I am familiar with these:
> >
> > - 802.11: WEP and WPA(2)-PSK keys can be configured via UAT. These
> > secrets normally do not change and UAT works fine here.
> > - SSL/TLS: a path to a keylog file can be configured, mappings from an
> > identifier to session secrets can be found in this file. Entries are
> > loaded at runtime as they are appended (making it usable for live
> > captures). UAT would not be usable as it is loaded only once.
> >
> > One way to solve the ZigBee problem is by using this separate file
> > approach? The dissector would then read keys from this file (instead of
> > UAT), a separate Lua post-dissector could be written to append to this
> > file.
> >
> > FWIW, for another protocol I also had the need to load external session
> > secrets during a live capture, these were also loaded from file:https://github.com/Lekensteyn/wireguard-dissector
> > --
> > Kind regards,
> > Peter Wuhttps://lekensteyn.nl
> >
> >
> ___________________________________________________________________________
> 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@xxxxxxxxxxxxx?subject=unsubscribe
--
Kind regards,
Peter Wu
https://lekensteyn.nl
