All,

SSL proxies work extremely well in practice, and they're an excellent way
of buffering SSL transactions between rogue clients and web servers.

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.

You're right about one thing, though: You can't advertise your real server
and have the proxy sitting transparently in the middle. You have to
advertise the PROXY as the real server. For example:

Before: Client <-> www.loser.com (real web server)

After: Client <-> www.loser.com (SSL Proxy) <-> internal.loser.com (real
web server)

And as you say, the proxy will have clear-text access to the
application-level data, as it should. Otherwise, what's the point in having
a proxy?

Regards,

Christopher Zarcone
Internetworking Consultant
RPM Consulting, Inc.
7130 Minstrel Way, Suite 230
Columbia, MD 21045
[EMAIL PROTECTED]

Date: Fri, 5 Feb 1999 10:30:40 +0200
From: Jan van Rensburg <[EMAIL PROTECTED]>
Subject: RE: Routing protocols thru firewall

hi,

> does anyone know of a proxy that will sit as a man-in-the-middle ona
> firewall to pass SSL trafic, but have it decrypted on the firewall to
> allow for the type of scanning that is desired?

i can't see how that would work. there was a discussion about this on this
list a while ago, and at first i thought it would be a pretty good idea. an
ssl proxy with it's own certificate, decrypting the stream from the server
and then encrypting it to the client with it's own certificate. however,
based on the url the client browser (at least msie & netscape) will refuse
or warn you that it is not a valid certificate. so at the very least it
won't be transparent, and the client will never be sure that he is actually
talking to www.mybank.com. the proxy will however be able to verify this,
which means the browser has to trust the proxy. (which i guess it has to do
anyways, 'cause the proxy has clear-text access to information that's
supposed to be private). please correct me if i'm wrong - cryptographer i
am
not.

- --jan van rensburg


-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]

Reply via email to