Suddenly getting lot of TLS decoder related alerts from Suricata
-
Since yesterday evening from around 5 PM UTC, I've been getting a steady amount of "SURICATA TLS invalid certificate" and "SURICATA TLS certificate invalid length" alerts from valid hosts, such as Apple's iCloud, Microsoft store and Azure.
I'm running 2.3.4-RELEASE (amd64) with Suricata 3.2.1_1 that has paid Snort rules and ETOpen. I've checked both Snort changelogs for 2990 (for the sake of it) and ETOpen changelogs (https://rules.emergingthreats.net/changelogs/suricata-1.3.open.2017-05-17T20:51:23.txt) that nothing has been changed in any TLS_ related rules.
Am I being targeted by the NSA here or what's going on? ::) Any ideas?
05/19/2017-00:20:16.457983 [] [1:2230004:1] SURICATA TLS invalid certificate [] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} n.n.n.29:56158 -> 74.125.131.188:5228
05/19/2017-00:20:16.457983 [] [1:2230007:1] SURICATA TLS certificate invalid length [] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} n.n.n.29:56158 -> 74.125.131.188:522874.125.131.188 for example is used by Google.
The original rules in my tls-events.rules for these two alerts are:
alert tls any any -> any any (msg:"SURICATA TLS invalid certificate"; flow:established; app-layer-event:tls.invalid_certificate; flowint:tls.anomaly.count,+,1; classtype:protocol-command-decode; sid:2230004; rev:1;)
alert tls any any -> any any (msg:"SURICATA TLS certificate invalid length"; flow:established; app-layer-event:tls.certificate_invalid_length; flowint:tls.anomaly.count,+,1; classtype:protocol-command-decode; sid:2230007; rev:1;) -
The error is being generated by one of the built-in rules of Suricata. I would suggest checking over on the Suricata Redmine site to see if anyone else has posted the same or similar issue. If the alert is coming from the rule I think it is, then the only thing that changes that rule is an actual update of the entire Suricata binary package. There is a core set of event and app-layer rules that install with the package (DNS events is one I recall, and I think there is a TLS events rule file as well).
Here is their Redmine site: https://redmine.openinfosecfoundation.org/projects/suricata
Taking a quick look myself, I found this TLS bug. I don't know if it applies in your case, but you can check out the thread here: https://redmine.openinfosecfoundation.org/issues/2050
Bill
-
Thanks Bill for your ideas, though I didn't find anything that quite fits the bill on the Suricata Redmine.
I checked that my clock is set and functioning, then rebooted my pfSense instance and I'm still getting these errors. For example, at the very same second, I've got like 10 rows from/to the same IPs to my logs about this:
[] [1:2230004:1] SURICATA TLS invalid certificate [] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 68.232.35.172:443 -> nnn.nnn.nnn.35:50801
So I've enabled TLS logging in Suricata to get the thumbprints and thus I can see the "invalid" certificate is actually valid without any issues:
nnn.nnn.nnn.35:50801 -> 68.232.35.172:443 TLS: Subject='C=US, ST=California, L=San Francisco, O=Twitter, Inc., CN=*.twvid.com' Issuerdn='C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 High Assurance Server CA' SHA1='fa:29:8e:8a:5e:2c:3d:fb:77:58:da:11:e7:1c:03:36:cc:b3:de:a0' VERSION='SSLv2' NOTBEFORE='2016-08-04T00:00:00' NOTAFTER='2019-10-02T12:00:00'
Again, this is now happening for certs from Google, Twitter, iCloud, Microsoft etc.
I just can't figure out what's going on :-\ :-\ :-\ - this isn't happening to anyone else?
-
…and oh yes, even forum.pfsense.org is affected :-X
[] [1:2230004:1] SURICATA TLS invalid certificate [] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} nnn.nnn.nnn.35:58745 -> 208.123.73.18:443
For a brief moment I wondered if I was sending some client certificates which are not working, but I'm seeing these errors also from iPhones doing some iCloud stuff, so I guess it's not client related in any way either. I'm getting confused here >:(
-
And you said this problem just popped up out of the blue after things had been working fine? A rules update from neither Snort VRT nor Emerging Threats would update this particular rule. It is part of the core set of rules provided in the Suricata source code and gets updated when the binary version changes.
The last Suricata update was to version 3.2.1 of the binary (and thus of these built-in rules). So do you know if your problem happened well after you updated to the 3.2.1 binary version, or could those two be related? I'm trying to pin down if this perhaps happened as a result of the 3.2.1 update. However, if it did, I would expect to be seeing more posts here about it.
Bill
-
I was able to get rid of the errors by shutting down ntopng!
Not sure what's wrong it with but in the logs I also saw this:
May 21 19:45:48 ntopng [HTTPserver.cpp:538] ERROR: Unable to start HTTP server (IPv4) on ports 3000s: Address already in use
Perhaps some upgrade gone bad :-\
-
Just in case anyone else has this issue. With suricata 5, just about any "strangeness" with a certificate gets marked as "invalid certificate". One such case is a missing Subject DN, which is the case with Active Directory LDAP certificates (they use Subject Alternative Name instead). It appears that with suricata 6 this will trigger an app-layer-event:tls.certificate_invalid_subject flag (most TLS issues now have their own flag), but that there are no alerts associated with this so hopefully it will go away.
