On Tue, 17 Aug 2010 11:43:38 -0400, "Bucci, David G" <david.g.bucci@xxxxxxxx> 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
