Re: SSL Vulnerabilities?

[czarcone () rpm com]

There are a lot of schools of thought on this. Rather than boring you with all
of them, I'll just bore you with mine :-)

The whole point of a proxy (in theory) is to act as a mediary between
client-server communications. To an extent, this involves understanding the
protocols being spoken, and in some cases analysis of application-layer data.

With SSL, both the protocol and the data are encrypted, which renders most
proxies useless. Your "SSL proxy" is nothing more than a TCP buffer shuttle,
just passing the data along because that's all it can realistically do. As such,
using a proxy doesn't buy you much more than a simple or stateful packet filter
would. About the only benefit you get is a cleanly-rewritten TCP stream, which
provides you with some insulation against IP- and TCP-layer attacks.

If you have a lower tolerance for risk, you could implement packet filtering in
parallel with a reverse proxy server (you could colocate it on your DMZ with
your webserver). Inbound connections could be packet filtered to the DMZ, hit
the RP, get decrypted, get inspected, then be relayed to your webserver for the
actual work. Your webserver's logs would still show all access coming from one
source (the RP) but that's OK. Your RP should now be able to provide you with
all the detailed access logs you want.

Regards,

Christopher Zarcone
Network Security Consultant
RPM Consulting, Inc.
#include <std.disclaimer.h>
My opinions are completely my own and based on no useful knowledge whatsoever,
and in fact should not be considered by anyone.

> From: Kyle Starkey <KSTARKEY () altera com>
> Subject: SSL Vulnerabilities?
> I am currently managing a DMZ for customer
> support at my company.  Our front end firewall is a NT based Gauntlet 5.0
> with only the SSL port open to the internet.  Since we are using the built
> in SSL/Http-Proxy, with the HTTP port blocked, the firewall intercepts the
> SSL packets changes the source IP address to its own and forwards the
> packets to the WebServer.  The problem with this is that the webserver logs
> show the firewall as the only one accessing it.  The Powers-that-Be would
> like to be able to see what pages are being accessed by what IP addresses.
> Our thoughts were to simply disable the proxy and use Packet filtering rules
> to manage the communications between the interent and the Webserver over the
> SSL port.  Other than the fact that NT is bad platform to sit your firewalls
> on, can any one think of any reason why this might be a BAD idea.