TLS DPD assumes TLS roles match TCP roles

The current TLS DPD signatures assume that the TLS client is the TCP originator and the TLS server is the TCP responder.

This is not always true, some appliances or middleboxes may have the TCP responder send the TLS ClientHello. In that case, TLS is not detected by DPD on non-standard ports.

I haven't reviewed the whole TLS parser, but from the code I checked and the tests I ran, flipped TLS roles seem to be handled correctly once the analyzer is enabled.

Would it make sense to let ClientHello / ServerHello determine the TLS role independently of the TCP roles?

I cannot share the original captures where I encountered this behavior, so I attached a PCAP generated with AI (gpt 5.6) to reproduce the case.

tls-clienthello-from-tcp-responder.pcap.gz