Suricata

I can't reproduce that with 5.0 beta anymore, can anyone confirm as well?

I tested it with HTTPS against my systems. What scenario did you have so I can see if I can transform it into a SV test?

See pcap from #3253

I only get one event:

{
  "timestamp": "2019-10-17T08:34:15.307866+0200",
  "flow_id": 276078541517555,
  "pcap_cnt": 12,
  "event_type": "tls",
  "src_ip": "192.168.0.43",
  "src_port": 58217,
  "dest_ip": "52.221.74.15",
  "dest_port": 443,
  "proto": "TCP",
  "tls": {
    "subject": "OU=vd, CN=fkp.samsungcloudsolution.com",
    "issuerdn": "C=KR, ST=Kyunggido, L=Suwon, O=Samsung Electronics, OU=SW2 SISC, CN=ROOT CA SISC FKP2_PLUS",
    "serial": "32",
    "fingerprint": "71:cd:fe:08:7f:3d:2a:18:32:69:38:fa:bd:64:7b:c6:cf:cc:44:8e",
    "sni": "fkp.samsungcloudsolution.com",
    "version": "TLSv1",
    "ja3": {},
    "ja3s": {}
  }
}

Run it against rules/tls-events.rules and check the alerts. You will see alerts for both sides for the same event.

Can you create the SV test? I don't see a reason for me to first confirm it.

https://github.com/OISF/suricata-verify/pull/223

Having looked at this :
Indeed events are directionless
It would be a good thing to match on the direction, but it should be optional

So implementing this would be :
- either have 2 stores for events (client and server), or using one bit of u8 to have the direction.
- Making all events addition setting the direction (that is the hard part)
- Have detect-app-layer-event.c parse an optimal direction and match on it if needed

I think this was fixed with #4759. I rebased the S-V test and gave it a run: https://github.com/jasonish/suricata-verify/actions/runs/4963447610

I rebased https://github.com/OISF/suricata-verify/pull/223 and now we have 0 events instead of 2 ...