Henrik, Referring to point 2, do you mean squid 3 supports https over some virtual directories while some other virtual directories still using http?
Is it applicable to authentication (with / without https) over certain virtual directories? Thx & Best Regards, Jonathan Chiu OLAPL OOCL Logistics (Hong Kong) Ltd. Unit 1, 4/F, Sun Hung Kai Centre 30 Harbour Road, Wanchai Hong Kong email: [EMAIL PROTECTED] Tel: 852. 2990-0174 Fax: 852. 2824-9017 -----Original Message----- From: Henrik Nordstrom [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 24, 2004 2:30 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [squid-users] reverse ssl problem. On Tue, 23 Mar 2004, Emre CELEBI wrote: > Configuration Summary: > > 1- squid as a reverse proxy in dmz also configured for ssl support. Ok. > 2- Web server (Unfortunately IIS cause of some fancy !!! vb/java script > programs) in the internal network to serve for both outside clients and > for internal clients.Some directorys on web publishing requie ssl > connection. this is a must. Then you need Squid-3, or if you are lucky you can surive with Squid-2.5 + SSL update patch. Squid-2.5 as distributed can not initiate SSL connections. > Question: Is there a way (like ssl tunneling?? dont know how to just know > about concept) to make squid connect to web server with ssl so that both > outside and inside clients use ssl to web server pages which setup with > ssl? You can use port forwarding / NAT to directly forward any requests for the https port to your web server without going via Squid. You obviously don't get the benefit if Squid access controls & logging when doing this, but instead gain full SSL capabilities including client certificates etc.. Regards Henrik IMPORTANT NOTICE Email from OOCL is confidential and may be legally privileged. If it is not intended for you, please delete it immediately unread. The internet cannot guarantee that this communication is free of viruses, interception or interference and anyone who communicates with us by email is taken to accept the risks in so doing. Without limitation, OOCL and its affiliates accept no liability whatsoever and howsoever arising in connection with the use of this email. Under no circumstances shall this email constitute a binding agreement to carry or for provision of carriage services by OOCL, which is subject to the availability of carrier's equipment and vessels and the terms and conditions of OOCL's standard bill of lading which is also available at http://www.oocl.com.
