Wireshark-dev: Re: [Wireshark-dev] Adding decryption keys at "runtime" (dissection time)
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 Wu
https://lekensteyn.nl
