Hi Henrik
Henrik Nordstrom wrote:
On Thu, 10 Feb 2005, Tobias Reckhard wrote:
[snip]
i.e. a client talks HTTP to Squid, it encrypts the communication using SSL, authenticates to the remote HTTPS server using a client certificate (and key), communicating with the remote HTTPS server across conventional HTTP proxies (, such as 'normal' Squids, using the CONNECT method).
See the cache_peer directive.
I have looked into it, as you probably noticed. :-)
I've read some pointers to cache_peer and http_port, but I haven't yet seen how to route the traffic _across_ an upstream proxy _to_ the final destination.
Hmm.. you are correct. Squid-3 does not know how to proxy https via a HTTP proxy. Didn't think anywone would want to do this when the https gatewaying was implemented in Squid-3, but it is a fairly simple thing to add if needed.
I do think it may be desirable in a few situations. Here, we're talking about Squid v3 acting as an SSL proxy for a group of clients that wish to access one or more SSL servers using client certificates, but who don't want to issue every client an individual certificate. These folks mandate that all HTTP/HTTPS traffic take place across conventional web proxies supporting the CONNECT method, which is probably a rather commonplace requirement.
What is needed for this to work is a native implementation of a CONNECT client when forwarding https:// URLs via a HTTP proxy, this would make the process
1. HTTP request received by Squid on http_port, and internally rewritten to a https:// URL.
2. Forwarded via a cache_peer not using the originserver option
3. Forwarding in Squid-3 here needs to be teached to use the CONNECT method to establish the connection and then switch to on origin server class SSL request.
Today the request will be forwarded as a https:// URL to the HTTP proxy, probably not what you want.
Exactly. I need the SSL (Reverse) Proxy to behave like a 'normal' web client with a configured HTTPS proxy. They tend to use CONNECT.
What you can do today without adding native CONNECT client support to Squid-3 is to run a small CONNECT relaying proxy for Squid to use, connecting to the web server in question via the HTTP proxy, and point the cache_peer directive to this CONNECT proxy.
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.
2. Squid v3 requests https://somesite from a separate CONNECT relaying proxy.
3. The separate CONNECT relaying proxy tranforms the https://somesite request into a CONNECT request and forwards this request to an upstream WWW proxy.
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.
Thanks for your time!
Cheers, Tobias
