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

On Tue, 17 Aug 2010 11:43:38 -0400, "Bucci, David G"
<david.g.bucci_at_lmco.com> wrote:
>> Squid *C* needs a cache_peer line for each separate certificate it
>> uses to contact Squid S.
>
> Getting back to this, Amos. Have roughed out the solution, but am now
> trying to layer in client certificates. Again, we have multiple
users/PC,
> but can guarantee that only one user will be on at a time (no concurrent
> logon and remote access sessions, e.g.).
>
> I guess I'm not understanding how to make sure that the tunnel
established
> between the squid instances (Client and Server) is authenticated with
the
> user-specific certificate. I had thought I would have to brute-force it

--
> e.g., have a known location for a user certificate, a cache-peer line
that
> points at that known location, and on user login have that particular
> user's certificate copied to that known location, then restart Squid C. 
> But your mention of a cache-peer line per certificate implies there's a
> more elegant approach?
Well, yes. Still a bit of a blunt object though.
> 
> Can you explain the above -- if I put a cache-peer line, pointing to a
> user-specific certificate for each user on the PC, how does Squid know
> which one to use?  Does it somehow do it dynamically, based on the
owning
> user of the process issuing the incoming request?
The idea goes like this:
 cache_peer can be configured with a client certificate (one AFAIK).
 cache_peer can be selected based on arbitrary ACL rules
(cache_peer_access).
 username can be found and matched with an ACL.
So... every user can have their own unique cache_peer entry in squid.conf
which sends their certificate out. :)
For easy management if you have more than a few users, I'd throw in the
"include" directive and have a folder of config snippets. One file per user
with their whole snippet included. Since its user specific and all are
identical the sequence of snippets is not to important between themselves.
The problems remaining is that username has to be checked and cached in
the main access controls (http_access) so that it becomes usable to
cache_peer_access.
What we end up with is:
/etc/squid/users/snippet-JoeBlogs:
  # match only this user
  acl userJoeBlogs proxy_auth JoeBlogs
  # forces the username to be looked up early. But !all prevents the allow
happening.
  # if you have more general access controls that use a "proxy auth
REQUIRED" this can be skipped.
  http_access allow userJoeBlogs !all
  # private link to the master server for this user
  cache_peer srv.example.com parent 443 0 name=peer-JoeBlogs ssl ...
  cache_peer_access peer-JoeBlogs allow userJoeBlogs
  cache_peer_access peer-JoeBlogs deny all
/etc/squid/squid.conf:
  ...
  auth_param ....
  ...
  include /etc/squid/users/*
  http_access deny all
> 
> If I do have to brute-force it, do you know if the Windows version
accepts
> env vars in squid.conf, e.g. %HOMEPATH%?  (may be a q. for Acme)  The
No. There is some limited support in specialized areas using the registry.
But not for files like that AFAIK.
Amos