Ok, Amos, now I finally understand in detail what you suggested below ... and cool as it is, it won't work for us. To review, what you outlined is an approach to having client software on the PC authenticate to the local squid (forcing the authentication with an "http_access allow !all"). Then, using the established identity, an SSL connection using that user's certificate is selected/created via a cache_peer line unique to that user. And that's the problem - the whole point of this exercise is that this 3rd party software we've been handed doesn't _support_ any authentication mechanisms ... not coded for Kerberos/NTLM, won't handle SSL client certs, not even basic auth. We're trying to impose the channel security from the outside. So, open to other ideas, but I'm back to having to securely copy the user's SSL cert to a known location on login, and force a squid -k reconfigure, so their cert is in use -- as basically an indirect way of extending the domain authentication that occurred at login. But all that said ... it's an innovative idea, what you outlined! -----Original Message----- From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx] Sent: Tuesday, August 17, 2010 8:44 PM To: Bucci, David G Cc: squid-users@xxxxxxxxxxxxxxx Subject: Re: 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@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
