[Oisf-users] Suricata SSL decryption

[Cooper F. Nelson]

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.

-- 
Cooper Nelson
Network Security Analyst
UCSD ITS Security Team
cnelson at ucsd.edu x41042

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20181105/145bfe09/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20181105/145bfe09/attachment.sig>