Re: [squid-users] Feasibility - Squid as user-specific SSL tunnel (poor-man's VPN)

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Tue, 03 Aug 2010 23:39:05 +1200

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
Received on Tue Aug 03 2010 - 11:39:13 MDT

This archive was generated by hypermail 2.2.0 : Tue Aug 03 2010 - 12:00:02 MDT