Suricata TLS support
Victor Julien has just merged to main tree a branch containing some interesting new TLS related features. They have been contributed by me and Jean-Paul Roliers.
This patchset introduces TLS logging and brings some new keywords to Suricata engine.
Here’s the list of all TLS related keywords that are available in latest Suricata git:
- tls.version: match on version of protocol
- tls.subject: match on subject of certificate
- tls.issuerdn: match on issuer DN of certificate
- tls.fingerprint: match on SHA1 fingerprint of certificate
- tls.store: store the certificate on disk
You will find detailed explanation below.
TLS handshake parser in Suricata 1.3
In Suricata 1.3, Pierre Chifflier has contributed a TLS handshake parser which allows Suricata to analyse the TLS parameters of a connection.
The first available keywords were tls.subject and tls.issuerdn. They allow the writing of rules similar to this one:
alert tls any any -> any any (msg:"forged ssl google user";
tls.subject:"CN=*.googleusercontent.com";
tls.issuerdn:!"CN=Google-Internet-Authority"; sid:8; rev:1;)
Here, suricata will alert if a certificate for CN=*.googleusercontent.com is not signed by CN=Google-Internet-Authority.
An other TLS related feature present in Suricata is the tls.version which allow you to match on the version of the protocol.
TLS Features included in the upcoming Suricata 1.4
TLS logging
Suricata can now log information about all TLS handshakes in a custom file. To activate this feature, you can add to your suricata.yaml file:
outputs:
# a line based log of TLS handshake parameters (no alerts)
- tls-log:
enabled: yes # Log TLS connections.
filename: tls.log # File to store TLS logs.
extended: yes # Log extended information like fingerprint
This will create a tls.log file that will contain information about TLS handshake:
08/27/2012-17:32:12.951518 2a01:0e35:1394:5ed0:0212:15ff:fe45:52bd:37957 -> 2001:41d0:0001:9598:0000:0000:0000:0001:443 TLS: Subject='OU=Domain Control Validated, OU=Gandi Standard SSL, CN=home.regit.org' Issuerdn='C=FR, O=GANDI SAS, CN=Gandi Standard SSL CA' SHA1='f3:40:21:48:70:2c:31:bc:b5:aa:22:ad:63:d6:bc:2e:b3:46:e2:5a' VERSION='TLS 1.2' 08/27/2012-17:45:07.812823 2a01:0e35:1394:5ed0:0212:15ff:fe45:52bd:56158 -> 2a00:1450:4007:0803:0020:0000:0400:100c:443 TLS: Subject='C=US, ST=California, L=Mountain View, O=Google Inc, CN=*.googleusercontent.com' Issuerdn='C=US, O=Google Inc, CN=Google Internet Authority' SHA1='c7:51:ea:f3:80:fa:ee:6e:3c:16:28:35:44:51:94:30:2d:76:31:9d' VERSION='TLS 1.1' 08/27/2012-17:45:13.600843 192.168.12.149:50035 -> 199.59.148.21:443 TLS: Subject='C=US, ST=CA, L=San Francisco, O=Twitter, Inc., OU=Twitter Security, CN=tdweb.twitter.com' Issuerdn='C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert High Assurance CA-3' SHA1='4e:f3:3f:92:86:cf:52:6c:74:e9:fc:40:d0:d7:9d:f2:4e:e4:91:1f'VERSION='TLS 1.1'
This can be used for statistical study and other usages.
TLS fingerprint match
The new keyword tls.fingerprint allows you to match on the fingerprint of a server certificate.
It allows you to write rules such as:
alert tls any any -> any any (msg:"Regit fingerprint";
tls.subject:"CN=home.regit.org";
tls.fingerprint:!"f3:40:21:48:70:2c:31:bc:b5:aa:22:ad:63:d6:bc:2e:b3:46:e2:5a"; sid:114; rev:1;)
Here, Suricata will alert when a certificate subject matches the one of home.regit.org but has not the correct fingerprint.
The SHA1 for a certificate can be retrieved from the tls.log file as well as from openssl or a browser.
$ openssl x509 -in cert.pem -fingerprint SHA1 Fingerprint=F3:40:21:48:70:2C:31:BC:B5:AA:22:AD:63:D6:BC:2E:B3:46:E2:5A
TLS store keyword
This last keyword permit to store server certificate and works in a similar way as suricata file storage. It does not take any arguments and trigger the storage of the certificate on the filesystem.
Our home.regit.org rules can be improved to store the certificate by simply adding tls.store to it.
alert tls any any -> any any (msg:"Regit fingerprint";
tls.subject:"OU=Domain Control Validated, OU=Gandi Standard SSL, CN=home.regit.org";
tls.fingerprint:!"f3:40:21:48:70:2c:31:bc:b5:aa:22:ad:63:d6:bc:2e:b3:46:e2:5a";
tls.store; sid:114; rev:1;)
Each certificate chain is stored in a separate PEM file and a meta file is a generated too. For example, a simple mach will create the following files:
- 1346085544.64714-1.pem
- 1346085544.64714-1.meta
The content of the meta file similar to this:
TIME: 08/27/2012-18:39:04.064714 SRC IP: 2a01:0e35:1394:5ed0:c147:93c6:8654:70fd DST IP: 2001:41d0:0001:9598:0000:0000:0000:0001 PROTO: 6 SRC PORT: 53494 DST PORT: 443 TLS SUBJECT: OU=Domain Control Validated, OU=Gandi Standard SSL, CN=home.regit.org TLS ISSUERDN: C=FR, O=GANDI SAS, CN=Gandi Standard SSL CA TLS FINGERPRINT: f3:40:21:48:70:2c:31:bc:b5:aa:22:ad:63:d6:bc:2e:b3:46:e2:5a
The whole certificates chain is stored in the PEM file:
-----BEGIN CERTIFICATE----- MIIE2DCCA8CgAwIBAgIQXszObihffqDbQdTwC+ycCjANBgkqhkiG9w0BAQUFADBB ... 3WCiQrY7P56JbvG4jNJ5H4ERj90hQquHj/8Ej39db/MCCmNgjRLVLdVkW4l5DRCe XX2Ac2xzZtLpVmft7sE3mQauGjW9tgCtpB/fxQqiA+uq+vm1PE37ukscByM= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIEozCCA4ugAwIBAgIQWrYdrB5NogYUx1U9Pamy3DANBgkqhkiG9w0BAQUFADCB ... 8/ifBlIK3se2e4/hEfcEejX/arxbx1BJCHBvlEPNnsdw8dvQbdqP -----END CERTIFICATE-----
This allow you to get all needed information during analysis.
Have fun
All theses features are available for testing in the latest Suricata git. All feedbacks are welcome.