<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>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. <br>
</p>
<p>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:<br>
</p>
<p> </p>
<blockquote type="cite"><a class="moz-txt-link-freetext"
href="https://wiki.squid-cache.org/Features/SslPeekAndSplice">https://wiki.squid-cache.org/Features/SslPeekAndSplice</a></blockquote>
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.
<p>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.
<br>
</p>
<p>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. <br>
</p>
<p>-Coop<br>
</p>
<div class="moz-cite-prefix">On 11/4/2018 6:38 PM, F.Tremblay wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAKF9Ee8DC+oxZRbuMdkijwi9DON0iSCKM4ectrqP_h40ZpFvCw@mail.gmail.com">
<div>Nothing personal Coop, just seems odd when plp talks about <i>vendors
</i>in an open source project.</div>
<div><br>
</div>
<div>Like saying go to Bluecoat in a squid forum.</div>
<div><br>
</div>
<div>Michal is right, the way to do it is to send Suricata
decrypted traffic.</div>
<div><br>
</div>
<div>Look at the work of Sonertari with SSLproxy, also MiTMproxy
and python.</div>
<div>
<h3 class="gmail-iw"><span style="font-weight:normal"><a
href="https://github.com/sonertari/SSLproxy"
moz-do-not-send="true">https://github.com/sonertari/SSLproxy</a></span></h3>
<div>And if you are anywhere between NYC and Toronto, Ill set
you up with an open souce solution to inspect encrypted
traffic.</div>
<div><br>
</div>
<div>No black box.<br>
</div>
<div><br>
</div>
<div>Cheers.</div>
<div><br>
</div>
<div>F.</div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Cooper Nelson
Network Security Analyst
UCSD ITS Security Team
<a class="moz-txt-link-abbreviated" href="mailto:cnelson@ucsd.edu">cnelson@ucsd.edu</a> x41042</pre>
</body>
</html>