[Snort-users] encrypted traffic

Victor Roemer viroemer at ...589...
Mon Aug 10 18:16:37 EDT 2015

Marcio, some explanations inline

On 8/10/15 09:59, Marcio Guerreiro wrote:
> Hi all
> I have a question… I hope you guys can suggest me something to read 
> about it…
> Considering that a great number of websites use SSL and the Snort 
> documentation suggests that we should *not enable encrypted traffic 
> verification*.. what it is going to happen ?
Where do you see the words "Encrypted traffic verification", the keyword 
being "verification".

Snort with ssl preproc can "detect" when ssl traffic finishes handshake 
and goes encrypted; but once it encrypted, there is little that can be 
done. Snort does not have built-in SSL decryptor, so tracking tcp 
connection and evaluating IPS rules etc. is, in general, an waste of 

> 1 - Should Snort be deployed with powerful hardware capable to deal 
> with the expensive computational demand generated by encrypted traffic ?
see above
> 2 - Should I remove *noinspect_encrypted from my snort.conf* and 
> enable the encrypted verification ?

 From what I'm reading; I would not suggest removing the setting.
> 3 - if I enable that, will Snort verify the whole packet contents ? 
> (data payload)
Snort does not do decryption of SSL, so if you're asking "if I disable 
noinspect_encrypted, will I be safe from malevolent HTTP 
servers/clients?" the answer is no.

What you need, is an SSL Proxy to perform the SSL termination 
(encryption/decryption) that runs separate from your application (e.g., 
HTTP server). In between the SSL Proxy and the HTTP server/clients is 
where you would deploy Snort.

Doing a setup like this can be daunting. Configuration tweaking alone 
will become mind-numbing as google search results fail
to yeild useful examples.

If the DIY is too much of an learning curve, there does exist non-free 
commercial products that tackle this directly. At Cisco, our NGFW 
products provide this capability without extra overhead of separate 
systems- the best part is that they do not require sending plaintext from
your application to an SSL terminator.

Please note, that I would not normally sugest non-free software on the 
list; I am not familiar with any alternative that is feature complete, 
secure, and readily deployable.

P.s., if you want to learn more on the subject, search google for 
/*mitmproxy*/. It's preaty cool tool.

> Thank you
> Marcio
> This body part will be downloaded on demand.
> This body part will be downloaded on demand.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20150810/34151802/attachment.html>

More information about the Snort-users mailing list