[Oisf-devel] [Emerging-Sigs] SSL Renegotiation

[L0rd Ch0de1m0rt]

On 11/9/11, Victor Julien <victor at inliniac.net> wrote:
> On 11/01/2011 02:27 PM, L0rd Ch0de1m0rt wrote:
>> Hello.  It looks like VRT is a week behind ET, lol.  But seriously,
>> for the proposed VRT rules in snort you have to disable, 'preprocessor
>> ssl: noinspect_encrypted' which means now snort is inspecting *all* of
>> your SSL traffic and for many of us who have a lot of public facing
>> websites that use SSL, this means inspecting *loads* more traffic,
>> 99.999% of it we don't care about anyway.
>>
>> I am now curious, does Suricata offer a better way to do this?  If
>> not, is there a similar configuration like 'preprocessor ssl:
>> noinspect_encrypted' that needs to be disabled?  Or is there an 'alert
>> ssl ... ' application layer rule that can be written?  I know Suricata
>> (or at least recent versions) support the 'ssl_state' keyword now.  I
>> copied the OISF devel list too so maybe they can shed some light on
>> this (assuming my email gets through).
>
> Just checked this out and it seems we do something similar, kind of.
>
> There is a setting "tls.no_reassemble" which defaults to true. What it
> does is it tells Suricata to stop reassembling the TCP streams (and thus
> parsing the SSL/TLS session). What it does not appear to do is stopping
> inspection of the packet payloads of that TCP session.
>
> By stopping the reassembly we do loose a significant part of the
> detection capabilities for that stream though.
>
> It may actually make sense to change this into the following:
>
> 1. keep tracking the SSL/TLS session so we can spot renegotiations.
> 2. have the SSL/TLS parser flag the parts of the stream that are
> encrypted and bypass those in the detection engine.
>
> Would that make sense?
>

Hello. Sounds good to me; I say ignore the encrypted stuff but don't
ignore stuff that you can reliably detect on like handshake,
renegotiation, etc.  Basically exactly what you said :)

-L0rd C.