Project

General

Profile

Actions

Bug #1936

closed

Can't set fast_pattern on tls_sni content

Added by David Wharton about 8 years ago. Updated about 8 years ago.

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

Description

The tls_sni sticky buffer was introduced in Suricata 3.1. Looking at the code, content matches in this buffer can be used for fast_pattern. However, when 'fast_pattern' is explicitly set on content in the tls_sni, buffer, an error is generated:

<Error> - [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - fast_pattern found inside the rule, without a content context. Please use a content based keyword before using fast_pattern

Here is an example rule that generates the error:

alert tls any any -> any any (msg:"ton.twimg.com SNI"; flow:established; tls_sni; content:"ton.twimg.com"; fast_pattern; sid:213321;)

If you remove the explicit 'fast_pattern;' piece and run fast pattern analysis on the rule you can see that the engine does in fact use it as the fast pattern match:

== Sid: 213321 ==
alert tls any any -> any any (msg:"ton.twimg.com SNI"; flow:established; tls_sni; content:"ton.twimg.com"; sid:213321;)
    Fast Pattern analysis:
        Fast pattern matcher:         Flags: None
        Fast pattern set: no
        Fast pattern only set: no
        Fast pattern chop set: no
        Original content: ton.twimg.com
        Final content: ton.twimg.com

============
Summary:
============
tls sni extension, smallest pattern 13 byte(s), longest pattern 13 byte(s), number of patterns 1, avg pattern len 13.00 byte(s)

If you need a pcap, see http://home.regit.org/~regit/flocon-tls.pcap

I tested this on Suricata 3.1.1 and 3.2beta1 with the same results.

Actions

Also available in: Atom PDF