[squid-users] RE: EXTERNAL: Re: [squid-users] Feasibility - Squid as user-specific SSL tunnel (poor-man's V

Thank you for replying! Couple clarifications - the solution IS for a known small set of domains, and all calls to those domains can have the solution applied.

The apps involved, we can't add SSL support in (don't ask, the answer is frustrating), and we likewise can't change the apps to send https:// URLs over HTTP. So the thought was they would use their existing HTTP URLs for the calls, and we would intercept and convert to HTTPS (with the same base URL) at the PC-hosted Squid proxy (URL rewriter?). Unfortunately, we can't send a client redirect, the software involved doesn't support SSL. So the rewriter would have to rewrite to SSL (is this supported?), so that Squid processes it as an SSL URL, including using the client certificate, on the way out. Then, the reverse proxy on the server would have to use just HTTP to get to its parent (that part is standard, right?)

All of that said -- your solution that uses the server's Squid as a cache-peer seems like it would work, and is very elegant. I'm confused, though -- the server side proxy would be configured as a regular proxy, not a reverse? I don't get that. Wouldn't it have to be a reverse, in order to forward the call on to the real web server? These are web service calls, they'll never actually be in cache. And if so, would that solution still work, using the server proxy in reverse proxy mode as a cache-peer?

-----Original Message-----
From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
Sent: Tuesday, August 03, 2010 7:39 AM
To: squid-users_at_squid-cache.org
Subject: EXTERNAL: Re: [squid-users] Feasibility - Squid as user-specific SSL tunnel (poor-man's V

Bucci, David G wrote:
> Hi, all - about to play with an approach to something, and I was
> hoping to bounce the idea off people here - pls let me know if that's
> not strictly within bounds/intents of the mailing list (new here).
> This is close to the same concept as discussed here with a D.Veenker,
> in an exchange in April/2010 -- but not quite the same.
>
> Is it possible to use Squid to create an ssh-tunnel effect, including
> use of a client certificate? This would be to layer in SSL and client
> authentication, for applications and web servers for which (for
> reasons I won't go into here) it's not possible to reconfigure/recode
> to use SSL.

Yes. I'd say "Trivial", but the surrounding SSL parts of it are not that simple.

>
> Concept would be to run Squid as a reverse proxy on the server,
> configured to do 2-way SSL (and doing HTTP to the parent server); then
> also run Squid on the client in standard proxy mode, likewise
> configured for 2-way SSL, pointing at a user's certificate via
> sslproxy_client_key.

As long as you control DNS for the website domain needing the HTTPS to make it point visitors to the domain at the Squid gateway.
This is a normal https_port configuration (note the "s").

>
> Constraints I see are that multiple users couldn't be using the
> solution on the PC at the same time; and Squid would have to be
> restarted (or whatever the Windows equivalent of a squid -k
> reconfigure is, I still have to figure that out) to establish the
> tunnel.

Yes. This is introduced by the use of user-specific certificates.

If you can get away from that (ie let Squid use a 'normal' default
certificate) then this problem disappears and it is just multiple clients using a localhost Squid.

>
> Does this seem feasible? Are there any potential gotchas that we
> should make sure we test early on, in attempting to achieve this?
>

One more comes to mind: client apps wanting Squid to perform the SSL wrapping need to send an absolute URL including protocol to Squid (ie https://example.com/some.file). They can do that over regular HTTP.
Squid will handle the conversion to HTTPS once it gets such a URL.

In the case where you have a small set of domains that are pre-known somehow there is an alternative setup which is much more in to a VPN than what you are currently thinking.

  Consider two squid setup as regular proxies: Squid C where the client apps connect and Squid S which does the final web server connection.

  Squid C gets configured with a parent cache_peer entry for Squid S with the SSL options.

  The domain names which require the HTTPS link are forced (via never_direct and cache_peer_access) to use the peer. Other requests are permitted to go direct and maybe denied access through the peer.

That is it.

Multiple users with per-user certificates just get multiple cache_peer entries (one per user certificate) for Squid S.

Amos

--
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.5