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
