I have nothing against a text keylog file approach, but FWIW with ESP UAT (or the run-time function I mentioned), you can configure the key in hex prefixed with 0x.
Martin On Thu, Aug 19, 2021 at 6:37 PM Nicolás Alvarez <nicolas.alva...@gmail.com> wrote: > El jue, 19 de ago. de 2021 a la(s) 08:30, Harald Welte > (lafo...@gnumonks.org) 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 > ___________________________________________________________________________ > 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
