>> 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 ;)
I guess the only reason why UATs are used for ISAKMP and ESP, whereas keylog files are used for TLS is because the respective dissectors where implemented by different people at different times.
Personally, I find the keylog approach much more elegant and easier to use. Apart from having to save the pcap and restart Wireshark, the UAT approach has some other drawbacks:
- There is no command line option to specify the UAT file paths. So you end up having to copy files in the Wireshark config directory or create symbolic links, and it is difficult to run several copies of Wireshark with different secrets.
- The UAT files are not reloaded automatically.
- Having an editable dialog is not a useful feature, because nobody nowadays would edit the secrets manually. As you said in general the secrets are the result of some ephemeral key exchange.
So the keylog file approach would be a cool feature to have. (PR welcome 😉 ) A good start would be to look at how the TLS dissector implements the monitoring and reloading. (Maybe the UAT files should remain for as a legacy feature a while, for compatibility reasons)
> 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.
I can confirm that binary secrets can be added using 0x<hexvalue>. The VPN client of my company autogenerates the 'ikev2_decryption_table' and 'esp_sa' UATs with binary secrets, see the second IPsec example https://gitlab.com/wireshark/wireshark/-/wikis/SampleCaptures#ipsec).
Matthias
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
