[Oisf-users] Fwd: suricata as SSL MITM

Andrey Terentyev andreycpp at gmail.com
Fri Aug 26 20:59:05 UTC 2016

Dear community,

I'm investigating ways to teach suricata do SSL decryption and act as SSL
MITM for the two most common scenarios - inbound SSL (suricata knows/owns
server's cert/key) and outbound SSL (suricata generates fake server
certificate on the fly using its CA cert and pretends to be the server to

I've googled on how to do this and only found a mention of "viewssld" which
reads packets with libpcap in parallel to suricata, decrypts then and emits
fake decrypted TCP traffic:

Now this may even for for the inbound SSL scenario, however it won't help
with outbound SSL. For the outbound SSL there are however a number of
opensource tools such as:
1) squid proxy's ssl-bump
2) http://mitmproxy.org/
3) https://www.roe.ch/SSLsplit

These tools can generate fake server certificate on the fly and decrypt all
the traffic. They however work with TCP streams rather than packets.

The challenge is basically to come with a solution for suricata. Do you
know of any way to make decryption work for suricata, possibly with the use
of above mentioned tools? Is this on the roadmap for suricata?

I'm thinking of two main integration approaches:
1) modify suricata code to do SSL MITM - here there are a bunch of
questions (which I hope you could help with):
- does suricata architecture today allow modification of packets / packet
data as they traverse thru various detection modules?
- what would be the best way to be the MITM - provided that suricata will
need to generate SSL traffic towards the client and server? This can be
done by generating full IP packets, or by establishing TCP connections like
squid/mitmproxy/splitssl do.

2) route all incoming SSL traffic into a separate SSL MITM daemon (e.g.
squid/mitmproxy/splitssl) and implement a custom module for suricata for
packet acquisition - e.g. the daemon could feed decrypted traffic into
This approach probably need less changes in suricata itself. I'm thinking
iptables rule for matching SSL traffic would be ideal - so that only SSL
traffic is passed into such daemon (this does not exist today, but can be

What would be your suggestion?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20160826/90180489/attachment.html>

More information about the Oisf-users mailing list