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.]
