Hi,<br>I agree with Shane.<br>You might want to give Nginx a try.<br>It is basically a load balancer/reverse proxy (open source, lives on Linux/Unix/Windows), with ability to use OpenSSL to effectively address the need for HW Accel.<br>
It is proven to be robust and light (11% of total current websites use it, including heavyweights like Facebook, Zappos, Groupon, LivingSocial, Hulu, TechCrunch, Dropbox and WordPress ) - <a href="http://nginx.org/">http://nginx.org/</a><br>
some more info and how tos - <a href="http://wiki.nginx.org/Main">http://wiki.nginx.org/Main</a><br><br>Three years ago they did some testing for WordPress - <a href="http://barry.wordpress.com/2008/04/28/load-balancer-update/">http://barry.wordpress.com/2008/04/28/load-balancer-update/</a> - the results are here.<br>
<br>If you would like to take a look at more open source suggestions for LB/HW Accl - <br><a href="http://www.ambitwire.com/lbc.html">http://www.ambitwire.com/lbc.html</a><br><br>Thanks<br><br><br><div class="gmail_quote">
On Mon, Nov 21, 2011 at 6:47 PM, Shane Anglin <span dir="ltr"><<a href="mailto:Shane.Anglin@knology.com">Shane.Anglin@knology.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
In regards to outbound web SSL traffic:<br>
For performance reasons, it is best to have a hardware SSL accelerator to do the MITM decrypting and encrypting... I am unaware of an open source project using a GPU for this (would like to hear if there is one though), but it should be feasible enough as some password cracker apps can use GPU computational power. There are approaches to doing the SSL interception with inline versus side-band (where data is duplicated to another path for investigation). What factors into much of this is if you need to make it transparent to the user or not. The only way to do this transparently is to have all the private keys for all the traffic being generated and load those onto the SSL interception device... depends on your environment, your access to your client's private key stores, internal policies & procedures, and whether you trust the SSL interception device with that critical data. Non-transparently, you could employ a proxy and force the users to go through it, but you then have to publish a SSL cert for the proxy and convince the users to trust that cert or forever receive SSL warnings... again, depends on your environment you are supporting and what policies you can enforce. Proxywise, the commercial ones I have used allow you to pass the traffic off to another device for investigation via PCAP, etc.<br>
<br>
Overall, if you want to decrypt the SSL sessions, you need the private keys (a big can of worms) or the ability to intercept the sessions to decrypt and encrypt to destination (a proxy and user acceptance and maintenance).<br>
<br>
Regards,<br>
<span class="HOEnZb"><font color="#888888"><br>
Shane Anglin GSEC, GCIH, GPEN<br>
Knology Broadband, Inc.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
-----Original Message-----<br>
From: <a href="mailto:oisf-users-bounces@openinfosecfoundation.org">oisf-users-bounces@openinfosecfoundation.org</a> [mailto:<a href="mailto:oisf-users-bounces@openinfosecfoundation.org">oisf-users-bounces@openinfosecfoundation.org</a>] On Behalf Of Martin Holste<br>
Sent: Monday, November 21, 2011 10:12 AM<br>
To: Robert Vineyard<br>
Cc: <a href="mailto:oisf-users@openinfosecfoundation.org">oisf-users@openinfosecfoundation.org</a><br>
Subject: Re: [Oisf-users] Decrypt ssl sessions<br>
<br>
Sounds like a great masters thesis for someone...<br>
<br>
On Mon, Nov 21, 2011 at 8:49 AM, Robert Vineyard <<a href="mailto:robert.vineyard@oit.gatech.edu">robert.vineyard@oit.gatech.edu</a>> wrote:<br>
> On 11/21/2011 9:33 AM, carlopmart wrote:<br>
>> Maybe it is an off-topic, but afaik suricata doesn't decrypts ssl<br>
>> sessions, correct?? But, exists some opensource tool that can do it<br>
>> and pass traffic to suricata to analyze it??<br>
><br>
> I don't think it's off-topic at all, and in fact is a feature that<br>
> would give Suricata a competitive advantage over many other IDS<br>
> systems - including Snort.<br>
><br>
> We've observed attackers utilizing encryption to mask their<br>
> activities, often sending malicious traffic over legitimate HTTPS or<br>
> SSH channels. This technique is generally successful in allowing them<br>
> to bypass traditional signature-based IDS setups.<br>
><br>
> There are some commercially-available products that either include SSL<br>
> decryption or offer it as an add-on, including one from Sourcefire.<br>
><br>
> I think a good first start if there's enough interest in pursuing this<br>
> type of functionality would be real-time decryption of private<br>
> key-escrowed legitimate traffic. A number of application-layer "next generation"<br>
> firewalls can do this with minimal additional overhead, particularly<br>
> considering some of the crypto-acceleration features built in to<br>
> recent CPUs from Intel and others - never mind the ongoing Suricata CUDA development.<br>
> GPU's could be leveraged for SSL decryption as well...<br>
><br>
> Unfortunately I don't really have much in the way of development<br>
> resources to offer here, but I may be able to provide testing<br>
> facilities in our high-traffic university environment where such a<br>
> feature would be heavily utilized.<br>
><br>
> --<br>
> Robert Vineyard, CISSP, RHCE<br>
> Senior Information Security Engineer<br>
> Georgia Tech Office of Information Technology<br>
> <a href="tel:404.385.6900" value="+14043856900">404.385.6900</a> (office/cell) / <a href="tel:404.894.9548" value="+14048949548">404.894.9548</a> (fax)<br>
> _______________________________________________<br>
> Oisf-users mailing list<br>
> <a href="mailto:Oisf-users@openinfosecfoundation.org">Oisf-users@openinfosecfoundation.org</a><br>
> <a href="http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" target="_blank">http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
><br>
_______________________________________________<br>
Oisf-users mailing list<br>
<a href="mailto:Oisf-users@openinfosecfoundation.org">Oisf-users@openinfosecfoundation.org</a><br>
<a href="http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" target="_blank">http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
<br>
_______________________________________________<br>
Oisf-users mailing list<br>
<a href="mailto:Oisf-users@openinfosecfoundation.org">Oisf-users@openinfosecfoundation.org</a><br>
<a href="http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" target="_blank">http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Peter Manev<br>
<div style="visibility: hidden; left: -5000px;" id="avg_ls_inline_popup"></div>