Project

General

Profile

Actions

Bug #698

closed

tls-log logging all TLS handshake is that working on current dev version?

Added by Alexandre Dulaunoy over 11 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
Affected Versions:
Effort:
Difficulty:
Label:

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
[19931] 7/1/2013 -
16:20:36 - (suricata.c:677) <Info> (SCPrintBuildInfo) -- compiled with _FORTIFY_SOURCE=2
[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,

Actions #1

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) ?

Actions #2

Updated by Eric Leblond over 11 years ago

Two other points:
  • 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)
Actions #3

Updated by Victor Julien over 11 years ago

Also, check for bad TCP checksums in your stats.log.

Actions #4

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.

Actions #5

Updated by Victor Julien over 10 years ago

  • Target version set to TBD
Actions #6

Updated by Andreas Herz over 8 years ago

  • Status changed from New to Closed

so more updates came

Actions #7

Updated by Victor Julien over 6 years ago

  • Target version deleted (TBD)
Actions

Also available in: Atom PDF