El jue, 19 de ago. de 2021 a la(s) 08:30, Harald Welte
(laforge@xxxxxxxxxxxx) escribió:
>
> Sorry if this has been covered before, but I could only find several
> locations online where the question has been asked, but no response anywhere:
>
> Is there already a mechanism by which a running wireshark can be triggered to
> re-load UAT tables at runtime, in my specific use case those for IKEv2 and ESP SA?
>
> I tried to grep for uat_load in the source but couldn't find any specific
> externally-triggered place other than doing a manual change and then pressing
> the cancel button, which will do a uat_load().
>
> I guess it should be relatively simple to add at least something like a SIGHUP
> or SIGUSR1 handler which would trigger the reload of the tables? The proper/fancy
> approach on Linux would of course be to use inotify/dnotfiy to get a notification
> from the kernel whenever some external program has updated those tables.
>
> The use case, in case it's not obvious, is to use an IPsec implementation that
> has been instrumented to update those tables automatically "in real-time" as new
> IKE handshakes or SAs are established. This is alerady possible e.g. from strongswan
> with a related plugin.
>
> Saving a pcap and opening it later on is of course always possible, but it seems
> rather clumsy to me, if there's no good reason against the good old "signal to re-read
> config files" approach.
The TLS dissector uses a text file with the keys, and I never had to
worry about manually reloading it. Apparently the way it works is that
every time a TLS packet is dissected, it checks again if there's new
lines in the file since the previous read. I'm not sure if it works if
a packet with decryptable data is captured before the corresponding
key appears in the text file though.
Isn't a main advantage of UATs that you get a GUI to edit it? How
common is it to use IPsec with pre-shared keys? If nowadays "everyone"
uses ephemeral randomly-generated keys, maybe using the GUI to
configure IKE/ESP keys is too cumbersome anyway, and the IPsec
dissector could use a text keylog file like the TLS and SSH dissectors
do instead of a UAT.
If there is a good reason to use UATs for this kind of encryption
keys, I'd wonder why the TLS and SSH dissectors don't use them ;)
(By the way, last time I tried this stuff, the ESP UAT expected me to
enter the raw key, not encoded in hex or anything, which doesn't work
if the key doesn't use printable ASCII characters, because it was
randomly generated and negotiated with IKE :/ )
--
Nicolás