You should check out www.celocom.com. The SSL proxy can be installed on teh firewall as well, eg gauntlet, Checkpoint and a bunch of others and you can use the SSL with any static port application [EMAIL PROTECTED] wrote: > 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.]
begin:vcard n:MacLeod;Calum tel;cell:+31 (0)653 448350 tel;fax:+31 (0)40 292 6633 tel;work:+31 (0)40 292 6632 x-mozilla-html:TRUE url:http://www.celocom.com org:Celo Communications;Benelux adr:;;Mirabelweg 108;Eindhoven;Brabant;5632PD;Netherlands version:2.1 email;internet:[EMAIL PROTECTED] title:Sales Manager fn:Calum MacLeod end:vcard
