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
Received on Thu Feb 10 2005 - 12:03:21 MST
This archive was generated by hypermail pre-2.1.9 : Tue Mar 01 2005 - 12:00:02 MST