Rudi,
Yes, by "proxy" I meant an application gateway. And of course, SSL can be
used with a variety of applications. I was using SSL in the context of
HTTPS, which is the most common case.
As I understand it, a proxy serves to moderate an application-level
conversation between 2 parties, usually a client and a server. To that
extent, it offers protection and control for BOTH involved parties. The
benefit is not unidirectional.
HTTP proxies also don't exist solely to catch malformed protocols or buffer
overflows. They also allow you to exert a fine degree of control over the
application protocol, and what specific operations can/can't be performed.
For example, an SSL proxy could prevent a client from sending a PUT
operation to the server. This prevents an illegal operation from reaching
your web server, which depending on its features/bugs/misconfiguration, may
or may not handle it well.
If the proxy is penetrated, then of course you're screwed, but only to a
limited extent. They would only have clear-text access to the data
transiting the proxy, and not ALL the data on your web server. It's all
about security in layers. Besides, if an attacker can break the SSL proxy
(which I have never personally seen or heard about) then I suspect your web
server isn't far behind...
As far as authorization, you're right, a lot of access control and auth has
to be performed by the proxy. This may or may not jibe with your web app
and its own security. It depends on your level of risk, and how far you're
willing to go to reduce it.
Regards,
Christopher Zarcone
Internetworking Consultant
RPM Consulting, Inc.
7130 Minstrel Way, Suite 230
Columbia, MD 21045
[EMAIL PROTECTED]
(800) 616-6579 pager
Date: Wed, 10 Feb 1999 17:51:03 +0100 (MET)
From: Rudolf Schreiner <[EMAIL PROTECTED]>
Subject: Re: SSL Proxy
On Tue, 9 Feb 1999 [EMAIL PROTECTED] wrote:
> SSL proxies work extremely well in practice, and they're an excellent way
> of buffering SSL transactions between rogue clients and web servers.
You mean an application level proxy?
SSL is not limited to HTTPS, I'm using IIOP/SSL.
> You can use a product like Netscape Proxy and give it its own certifcate,
> then configure it to "reverse proxy" connections to a secondary server
(the
> REAL web server). The secondary server can be SSL or not, it doesn't
really
> matter.
How do you do authentication between the client and the real server?
Does your proxy really protect the server from evil content in the HTTP
requests? Normal HTTP proxies protect the client from malicious
responses, not the server from the request.
What happens if your proxy is penetrated? The attacker has full
access to the encrypted data.
> Otherwise, what's the point in having
> a proxy?
I'm using a transparent TCP-level proxy to protect the server from evil
IP. (My proxy actually does much more, but that's IIOP and application
specific.)
The client authenticates directly to the server. Without this
authentication
I can't do authorisation on the server.
The risk of my system is a possible exploit of bugs in the server, e.g. a
buffer overflow. In our case we can live with this small risk.
Rudi
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
