[Oisf-users] Suricata SSL decryption

[Soner Tari]

Hi Coop,

You say that SSLproxy is single-threaded: 
http://lists.openinfosecfoundation.org/pipermail/oisf-users/2018-November/016311.html

I am the developer of SSLproxy, and I assure you that it has an event-
driven multithreaded design:

"SSLproxy is able to handle a relatively high number of listeners and
connections due to a multithreaded, event based architecture based on
libevent"

See sslproxy(1) here: 
https://github.com/sonertari/SSLproxy/blob/master/sslproxy.1

By default, SSLproxy starts twice as many number of connection handling
threads as the number of cores on the system it is running on.

HTH,
Soner


Cooper F. Nelson wrote:
> Most large deployments are going to have a switched hardware tap
> anyway
> (we do, to support other sensors and allow for redundancy), so buying
> one that can also decrypt TLS is a net positive I would think. 
> Offloading the decryption to dedicated hardware may also be necessary
> for large (e.g. 100Gb) deployments; plus you get so save your CPU
> cycles
> for detection. 
> 
> Squid was initially developed here @UCSD and I'm intimately familiar
> with the project.  I'm currently investigating whether the 'SSlBump
> Peek
> and Splice' feature can be leveraged to allow suricata to be
> integrated
> into a traditional forward proxy deployment:
> 
> > https://wiki.squid-cache.org/Features/SslPeekAndSplice
> 
> From what I can tell so far it looks like it will require new code to
> actually send the decrypted traffic somewhere (like a loopback
> interface) vs. just inspecting/logging.
> 
> I also have a 'pipe dream' of learning Rust and adding TLS decryption
> support to the current protocol handler; but the reality is that is
> probably outside of my capabilities.  And it would only work in a
> 'reverse' proxy deployment where you control the servers and can
> install
> the associated private key(s) on your sensor.  I'm not sure how it
> would
> work in a forward proxy mode and would probably require a separate
> software stack (like squid or nginx) to proxy the session and install
> your own private key.  One idea I had was to create something like a
> TLS
> 'gateway' you installed on the perimeter that would knock down TLS
> 1.3
> and 1.2 DHE sessions to a minimal 1.2 session that could be easily
> decrypted off the wire once the traffic was inside your network. 
> 
> I'm personally of the opinion that if you are *really* serious about
> inspecting TLS traffic you should build a true 'zero trust' network
> first; then setup a DMZ and an explicit forward proxy (no NAT!) to
> access external sites.  In that architecture you can easily drop
> something like SSLproxy in place to intercept and inspect encrypted
> traffic.  AFAIK SSLproxy is single-threaded, so I'm note sure how
> well
> it would work if deployed on a large (10Gb+) network.  For 1G
> deployments it works fine, though. 
> 
> -Coop
> 
> On 11/4/2018 6:38 PM, F.Tremblay wrote:
> > Nothing personal Coop, just seems odd when plp talks about /vendors
> > /in an open source project.
> > 
> > Like saying go to Bluecoat in a squid forum.
> > 
> > Michal is right, the way to do it is to send Suricata decrypted
> 
> traffic.
> > 
> > Look at the work of Sonertari with SSLproxy, also MiTMproxy and
> 
> python.
> > 
> > 
> >       https://github.com/sonertari/SSLproxy
> > 
> > And if you are anywhere between NYC and Toronto, Ill set you up
> > with
> > an open souce solution to inspect encrypted traffic.
> > 
> > No black box.
> > 
> > Cheers.
> > 
> > F.
> 
>