Re: [squid-users] Squid 3: Reverse Proxy with HTTPS and upstream proxy

From: Tobias Reckhard <[email protected]>
Date: Fri, 11 Feb 2005 11:44:53 +0100

Henrik Nordstrom wrote:
> On Fri, 11 Feb 2005, Tobias Reckhard wrote:
>
>> I'm not sure I fully understand, is the following right?
>>
>> 1. Client connects to Squid v3 and requests http://somesite, thinking
>> it's the origin server.
>
> or https://somesite, doesn't matter.

Right, if I supply Squid with a certificate and a private key that the
client will accept. In this specific case, these don't exist.

> if using http Squid v3 can even be contacted as a proxy.

Wow. I smell some pretty smart magic. :-)

> If using https the client need to think the Squid server is the origin
> server as the client SSL connection then should be terminated at the proxy.

Yes, my prior understanding of the situation agrees with that. Squid
seems to be rather unique in that it can transform requests, too. We've
been testing the same scenario with Apache and DeleGate and so far it
seems to me that they require the client to believe it's talking to the
origin server in every case.

>> 3. The separate CONNECT relaying proxy tranforms the https://somesite
>> request into a CONNECT request and forwards this request to an
>> upstream WWW proxy.
>
> Correct. A simple "plug" type proxy which when it gets a TCP connection
> from Squid connects to the HTTP proxy and issues a CONNECT request to
> the preconfigured https server.

Exactly.

>> 4. The upstream WWW proxy connects to the origin server and passes
>> through data across the established tunnel thereby.
>>
>> Since I currently don't have such a CONNECT relaying proxy, I guess
>> I'm out of luck momentarily, huh? ;-) I'll see if a search turns up one.
>
> socat looks reasonable. Kind of an swiss army nife for this kind of tasks..

I'll take a peek at it. Thanks for the hint.

Cheers,
Tobias
Received on Fri Feb 11 2005 - 03:45:11 MST

This archive was generated by hypermail pre-2.1.9 : Tue Mar 01 2005 - 12:00:02 MST