Suricata

I guess there is also the question of whats correct. Should the src_ip be the client even if the certificate comes from the server, like in IDS mode? Or is IPS mode more correct where the src_ip is the server, where the certificate comes from?

What about client certificates, when we would see a certificate from each side?

Don't think client certs are handled at all currently.

I was testing rules/alerts to see if they behaved differently with respect to IDS and IPS mode, and they don't which is good. But I did notice this:

RULE: alert tls [10.16.1.0/24] any -> any any (msg:"TLS RULE TEST"; tls.version:"1.2"; sid:1; rev:1;)
ALERT: "src_ip":"10.16.1.11","src_port":54684,"dest_ip":"24.244.4.23","dest_port":443

RULE: alert tls any any -> [10.16.1.0/24] any (msg:"TLS RULE TEST"; tls.version:"1.2"; sid:1; rev:1;)
ALERT: src_ip":"24.244.4.23","src_port":443,"dest_ip":"10.16.1.11","dest_port":54684

As this was in IDS mode, in both cases the TLS events was like:
event_type":"tls","src_ip":"10.16.1.11","src_port":54684,"dest_ip":"24.244.4.23","dest_port":443

The alert behaviour is consistent between IDS and IPS modes.

Tests done using https-www-google-com-head.pcap already attached.

Just realized that using the TLS version is probably not the best way to show this off as that would be in each direction, so I used tls.fingerprint instead. I get the same results.

I also added an "any any -> any any" rule with the finger print and I get 2 alerts, one with the client as the source and one with the server as the source.

I can confirm that we don't handle client certificates.

Shouldn't the src_ip always be the client? Since it's the one initiating the session.

Looking at how tls.fingerprint is implemented, it looks like it doesn't care about direction at all. It always try to match on the fingerprint from the server in the SSL state, even on packets from the client. Direction seems to be implemented on tls.subject and tls.issuerdn, so try using one of these keywords for testing instead. All the keywords in detect-tls.c are probably due for a reimplementation..