RE: [squid-users] reverse ssl problem.

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: jonathan.chiu@oocl.com
Tel: 852. 2990-0174
Fax: 852. 2824-9017

-----Original Message-----
From: Henrik Nordstrom [mailto:hno@squid-cache.org]
Sent: Wednesday, March 24, 2004 2:30 AM
To: ecelebi@havelsan.com.tr; emre22@europe.com
Cc: squid-users@squid-cache.org
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.
Received on Wed Mar 24 2004 - 00:01:37 MST