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

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
Received on Fri Feb 11 2005 - 01:54:30 MST