On Thu, 10 Feb 2005, Tobias Reckhard wrote:
Client -- HTTP --> Squid 3 ---> HTTPS with client certificate ---> HTTP proxy ----> HTTPS ---> HTTPS Server
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).
If so, how?
See the cache_peer directive.
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.
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.
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.
Regards Henrik
