Bug #2050
closedTLS rule mixes up server and client certificates
Description
Suricata Version 3.2.1
Trying to detect our own expired certificates with a rule as follows:
alert tls $HOME_NET any -> $EXTERNAL_NET any (msg:"expired certificate found"; flow:established,from_server; tls_cert_expired; tls_cert_subject;content:"mydom"; sid:1;rev:1;)
The idea behind this rule was to detect server certs. Now the alert triggered on a client cert (2-way SSL), and the alert output was mixed (server/client cert data):
... "tls": { "subject": "<subject_from_SERVER_cert>", "issuerdn": "<issuer_from_SERVER_cert>", "fingerprint": "<fingerprint_from_SERVER_cert>", "version": "TLS 1.2", "notbefore": "<date_from_CLIENT_cert>", "notafter": "<date_from_CLIENT_cert>" }, ...
Given he rule (traffic direction), I would have expected the client cert not to be considered here.
The client certificate DID have a matching tls_cert_subject in this case, though. I still consider it to be a bug (detection and mixed up logging).
Updated by Mats Klepsland over 7 years ago
Is it possible for you to recreate this, capture a pcap of the traffic and share it? You can share it privately if you like.
That would greatly simplify debugging this issue :)
Thanks for reporting the bug!
Updated by Mats Klepsland over 7 years ago
I think I just located the bug, but I will have to do some more testing before I can confirm this.
Updated by Mats Klepsland over 7 years ago
I can confirm that I've managed to reproduce the bug with the pcap you sent.
Updated by Mats Klepsland over 7 years ago
- Assignee set to Mats Klepsland
Submitted pull requests [1]2 to fix the bug.
[1] https://github.com/inliniac/suricata/pull/2599
[2] https://github.com/inliniac/suricata/pull/2600 (backport to 3.2.x)
Updated by Victor Julien over 7 years ago
- Status changed from New to Assigned
- Target version changed from TBD to 70
Updated by Victor Julien about 7 years ago
- Status changed from Assigned to Closed
- Target version changed from 70 to 4.0.1