Fwd: Re: SSL - Man-in-the-Middle filtering

["David Williams" <dwilliamsd () gmail com>]

I posted a message last week about various MITM SSL applications for
use with IDS/IPS where I mentioned the term "transparent" as proffered
by Netronome Systems.  The Netronome folks kindly replied to me with
some information to clarify their use of the term "transparent"  (I
have edited the email to remove references to anything other than the
term "transparent" and appended to the end of this email), and I
wanted to see if anybody could validate their use of the term
"transparent" as what the industry typically uses that term for.

Wikipedia seems to disagree with the Netronome folks: "A 'transparent
proxy' is a proxy that does not modify the request or response beyond
what is required for proxy authentication and identification". While
Wikipedia deescribe "Intercepting Proxy" as, "Connections made by
client browsers through the gateway are redirected through the proxy
without client-side configuration (or often knowledge)."

It would appear that the definition offered by Netronome of
"transparent" proxy is incorrect, and the term "intercepting proxy"
would be more accurate.  Does that seem accurate?  Or maybe, a
combination of both.

Regardless of semantics, the real question is, has anybody on this
list used the Netronome product in combination with their IDS/IPS
deployment?  And does anybody have any experience hacking snort onto
their appliance to avoid the two box scenario?  They're claiming on a
similar piece of hardware to do 6 to 8Gbps of Snort performance, so it
seems as though the SSL appliance from Netronome has plenty of
horsepower, and I'd just assume tap into it that horsepower since I
won't have nearly a full gig of SSL traffic (nor 6 to 8 Gbps of raw
network traffic).  Please contact me off list with info.

thanks,

-dave


forwarded message below:
=============================
Daniel Proch, Netronome PM wrote:

A transparent proxy is deployed in-line without IP addresses on the
interfaces.  Our device examines all traffic at line rate and
identifies SSL traffic, regardless of whether it is on port 443 or
not, by looking for the SSL handshake rather than just looking at TCP
port #s.  This allows us to identify SSL on non-standard ports and
also allows up to find connections that do not start out as SSL, but
change to SSL later (START TLS).    This transparency also means that
the SSL proxy function is hidden from the end user, removing the need
for time-consuming and costly client device and application
configuration.

In contrast, traditional SSL proxies require network IP address
configuration and likely need network topology changes to engineer the
appliance into the network as an active network element.  As an active
network element with IP addresses on the in-line interfaces, these SSL
Proxies are now vulnerable to all attacks just as any other host,
server, switch or router would be.  Careful consideration needs to be
given to the security of the SSL Proxy configuration itself in both
the data plane and management plane.  Another issue with network
designs based on SSL proxies is that these assume that all SSL traffic
is blocked except that which goes through the proxy. SSL applications
redirect traffic on port 443 to the proxy. SSL proxies are incapable
of detecting hidden SSL flows on different (non-443) port numbers
because such traffic is not directed to the proxy.  Traditional SSL
proxies also force costly changes to network topology, firewall and
policy configuration, as well as modification of client/server
stations and their SSL-capable applications in the enterprise.
Applications using SSL require the proxy server's information, such as
IP address, port number and, potentially, other security settings.
Finally, end users may still not have full trust that their personal
information is secure. They must trust the enterprise to behave
appropriately and not inspect their SSL communications that are of
acceptable-use.
============================
end forwarded message

------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it 
with real-world attacks from CORE IMPACT.
Go to http://www.coresecurity.com/index.php5?module=Form&action=impact&campaign=intro_sfw 
to learn more.
------------------------------------------------------------------------