Suricata

I believe anomaly logging incorrectly triggers on the attached suricata_1306651_alerts_tls.pcap traffic. Our investigation concludes that any TLS handshake so far (both 1.2 and 1.3) triggers alerts and anomaly logs on valid traffic. We have reproduced the issue with our own TLS clients (like Firefox, curl).

As far as my understanding goes, there's no invalid TLS record type in this conversation. It seems though, it is seeing TCP ACK as part of a TLS stream and alerting on this. But, I fail to really understand the alert-debug output. Second to this it also triggers a "protocol one direction" alert, which I don't see as valid as the conversation is completely recorded.

Regarding the pcap; these are captured via suricata pcap capture mode. Every packet is duplicate due to packets traversing multiple 802.1Q VLAN with id 100 and 250. First, we though this might be the cause of the issue, but after dropping all vlan 250 traffic, we still see the same issue, so that is irrelevant. The only interesting finding is that in the network before NAT, we don't get any alerts. So it might be due to oddity of our internal network setup also.

Please let me know if you want to have more information.

I validated this on suricata 7.0.7 using a somewhat default configuration. We use af-packet on a bond interface. There's no serious optimizations done to the configuration. If you need more specifics here please ask. The PCAP also triggers similar alerts on Suricata 6 with default configuration testing locally.