Search squid archive

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux