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
