-----Original Message-----
From: Amos Jeffries [mailto:[email protected]]
Sent: Tuesday, August 03, 2010 7:39 AM
To: [email protected]
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.
<snip>
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.
Bucci, David G wrote:
> 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.
>
<snip>
>
> 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?
>
Reverse-proxy handling is only needed if the clients are unaware that
its a proxy. It depends on DNS configuration for the domain pointing at
the gateway proxy, and does extra request handling to map a web-server
formatted request into something it can handle better.
Since this setup we know that both ends of the SSL link are proxies we
don't need any of that special handling. It's just a basic heirarchy of
two proxies which happen to SSL their link.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.6
Beta testers wanted for 3.2.0.1
