Multithreading within the SSL dissector

Question

A basic understanding in how the SSL dissector in wireshark works is like this

1. Determine packet content type ( App data, Key exchange, Alert, Handshake)
2. Append packet info to gui column.
3. Decode packet based on content type.
Specifically If content type is
A. Key exchange:

Read keylog file if available
Generate TLS secrets and add to a “decoder” structure. Change “SSL state” to a global constant if successful generation of keys.
Load decoder structure for the ssl_session.

B. App data:

If decoder is available for the session, decrypt the data.

I currently have a modified version of the SSL dissector such that it would enable remote decryption i.e. TLS session keys (not the keylog file) generated from another computer are sent to the gateway where my modified ssl dissector can use those keys to decrypt the data.

To do this, at some point I need to add a delay for every key exchange message to make sure that the appropriate TLS secrets have arrived inorder to create a decoder variable for that ssl session.

Because of the sequential nature of dissection in wireshark, the delay would eventually add up causing an undesirable performance.

Can someone please guide me on how I could avoid this problem or improve my code such that the delay does not accumulate. So far, I have looked at multithreading which is advised to be a big “No-No” for wireshark.

If multithreading is possible, could someone please tell me how do I proceed ? I am aware of this thread in the dev.

Sketch for remote decryption in wireshark can also be seen here

Accepted Answer

Multi-threading won't help you here, there is still a dependency between packets, and sometimes even between the ordering of TCP sessions (in the case of session resumption, though having the master secret for the resumed sessions helps a bit).

Your problem is the dependency on external data (the TLS master secrets). I see at least two options:

Modify the server to delay handshake completion until your tool acknowledged the receipt of the secrets.
Put a proxy tool between the endpoint and Wireshark that buffers packets until the master secrets become available. Specfically:
A packet capture is not sent directly to Wireshark, but via a proxy.
This proxy (which could be using tshark) provides: TCP Stream number (tcp.stream), Client Hello and handshake types. No decryption is needed yet, you only have to recognize (the contents of) a TCP packet.
Now the decision to forward packets to Wireshark or to buffer it. If it is a TLS session, then you forward it only if you know the secrets. Otherwise, you buffer packets for which the keys are needed (e.g. ChangeCipherSpec, Finished, Application Data). Optionally you can flush a buffer (and forward the packets) after reaching a certain time deadline to avoid filling up buffers that never get emptied.

The receiving side could use the Extcap API or just a simple pipe to stdin (your_proxy_tool | wireshark -i - -k).