Wireshark-dev: Re: [Wireshark-dev] Dissecting TLS and non-TLS using the same ports

From: Markku Leiniö <markku@xxxxxx>
Date: Thu, 13 Jul 2023 19:14:54 +0300
On 13.7.2023 18.10, John Thacker wrote:
On Thu, Jul 13, 2023, 10:49 AM Markku Leiniö <markku@xxxxxx <mailto:markku@xxxxxx>> wrote:

    In my Zabbix dissector I'm currently using
    dissector_add_uint_range_with_preference("tcp.port", ZABBIX_TCP_PORTS,
    zabbix_handle) to define the TCP ports (defaulting to "10050,10051").


The short answer is don't use ssl_dissector_add(), just

|dissector_add_uint_range("tls.port", zabbix_tcp_range, zabbix_protocol);|

There's also a version _with_preference that takes a string instead. That will be the same as what you did in Lua.

Ok, let me see. If I use dissector_add_uint_range_with_preference() with "tcp.port" and "tls.port" separately, order matters: the one that is first will be used (the other won't work).

If I only use it with "tls.port", then TLS+Zabbix works, plain Zabbix won't. And with "tcp.port" only plain Zabbix works, not TLS+Zabbix.

1. Register the non TLS version in the TCP port table, have it reject packets that are not Zabbix, the TLS heuristic dissector should pick it up if all goes well and forward it along after dissecting the TLS portion. Sounds like that worked for you on Lua, so it should work here.

In my current code (https://gitlab.com/markkuleinio/wireshark/-/blob/zabbix-dissector/epan/dissectors/packet-zabbix.c btw) I return 0 as soon as I see the packet is not Zabbix (= mismatch in magic values), but apparently that does not cause the TLS dissector to kick in.

2. Register the TLS version in the TCP port and a heuristic dissector for Zabbix; if the non TLS protocol doesn't look like TLS, the TLS dissector should reject it, and your heuristic dissector should pick it up.

That's something that I will have to still try, I believe README.heuristic will help me here.

3. Register some kind of helper dissector to the TCP port that can detect whether this is straight Zabbix or TLS, calling the TLS dissector if necessary. This can end up making `pinfo->layers` have an extra entry, especially for the first TLS packet in the first pass.

Probably TMI, because the first should work for you.

Could there be some other setting here now that affects the behaviour? I do have imported my usual Wireshark profile on the development VM that runs the compiled wireshark.exe, but I don't recognize any setting that affects this dissector chaining.

Markku