Bug #698
closedtls-log logging all TLS handshake is that working on current dev version?
Description
Hi All,
Following the following blog post at https://home.regit.org/2012/08/tls-fingerprint-store/
I was wondering if tls-log works as expected on the current 1.4dev version (rev 5f4c528).
The configuration for tls-log is the following:
- tls-log:
enabled: yes # Log TLS connections.
filename: tls.log # File to store TLS logs.
extended: yes # Log extended information like fingerprint
certs-log-dir: certs # directory to store the certificates files
But I got nothing in the tls.log file (even if there are many TCP streams reassembled).
Looking at the blog post, it seems that is a default behaviour of the module
but it's not clear if a rule is required to be associated to make the logging of all TLS active.
Suricata build version is the following:
[19931] 7/1/2013 -- 16:20:36 - (suricata.c:560) <Info> (SCPrintBuildInfo) -- This is Suricata version 1.4dev (rev 5f4c528)
[19931] 7/1/2013 -- 16:20:36 - (suricata.c:633) <Info> (SCPrintBuildInfo) -- Features: PCAP_SET_BUFF LIBPCAP_VERSION_MAJOR=1 AF_PACKET HAVE_PACKET_FANOUT LIBCAP_NG LIBNET1.1 HAVE_HTP_URI_NORMALIZE_HOOK HAVE_HTP_TX_GET_RESPONSE_HEADERS_RAW
[19931] 7/1/2013 -- 16:20:36 - (suricata.c:647) <Info> (SCPrintBuildInfo) -- 64-bits, Little-endian architecture
[19931] 7/1/2013 -- 16:20:36 - (suricata.c:649) <Info> (SCPrintBuildInfo) -- GCC version 4.6.3, C version 199901
[19931] 7/1/2013 -- 16:20:36 - (suricata.c:655) <Info> (SCPrintBuildInfo) -- __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1
[19931] 7/1/2013 -- 16:20:36 - (suricata.c:658) <Info> (SCPrintBuildInfo) -- __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2
[19931] 7/1/2013 -- 16:20:36 - (suricata.c:661) <Info> (SCPrintBuildInfo) -- __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
[19931] 7/1/2013 -- 16:20:36 - (suricata.c:664) <Info> (SCPrintBuildInfo) -- __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8
[19931] 7/1/2013 -- 16:20:36 - (suricata.c:667) <Info> (SCPrintBuildInfo) -- __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16
[19931] 7/1/2013 -- 16:20:36 - (suricata.c:671) <Info> (SCPrintBuildInfo) -- compiled with fstack-protector 16:20:36 - (suricata.c:677) <Info> (SCPrintBuildInfo) -- compiled with _FORTIFY_SOURCE=2
[19931] 7/1/2013 -
[19931] 7/1/2013 -- 16:20:36 - (suricata.c:680) <Info> (SCPrintBuildInfo) -- compiled with libhtp 0.2.11, linked against 0.2.11
and the following app layer are supported:
./suricata --list-app-layer-protos
=========Supported App Layer Protocols=========
http
ftp
smtp
tls
ssh
imap
msn
smb
smb2
dcerpc
dcerpcudp
=====
Thanks for your help,
Kind regards,
Updated by Eric Leblond over 11 years ago
Bonjour Alexandre,
I've just started a similar version (two completely unrelated patches on top of your version) and it works. I've done the same configuration as yours and I've started suricata with suricata --af-packet=wlan0
and got TLS logging in tls.log.
Can you provide your configure options and/or share a pcap if the packet source is a pcap (privately if needed) ?
Updated by Eric Leblond over 11 years ago
- no rules are necessary for TLS logging
- did you check that the tls.log was the good one (used by running suricata as shown by lsof by example) ? (stupid question but it is better to get rid of stupid thing first)
Updated by Victor Julien over 11 years ago
Also, check for bad TCP checksums in your stats.log.
Updated by Alexandre Dulaunoy over 11 years ago
Hi Eric, Hi Victor,
Thanks a lot for the feedback.
After some hours, I got some lines (yeah!) but not a lot compared
to the number of TLS sessions actives:
wc -l tls.log
6 tls.log
and indeed there are some "tcp.invalid_checksum | Detect | 74"
For this Suricata, I'm not using PF_RING and the offload is active:
Offload parameters for eth1:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: on
The ethernet frame are 802.1q tagged but I suppose this should not make any differences.
I'll try to make a more appropriate test-case using various TLS handshake and come back to you when I have some
pcap that I can share. Until now, I'll close the ticket.
Thanks a lot for your work.