Hmm ... no, but thank you. Right now, fighting Squid Windows SSL problems ... if I emerge successfully from that, I may try what you suggest. It basically actss as a kerberized version of the HTTP caller, wrapping the call in SPNEGO support or something? -----Original Message----- From: Markus Moeller [mailto:huaraz@xxxxxxxxxxxxxxxx] Sent: Wednesday, August 25, 2010 2:43 PM To: squid-users@xxxxxxxxxxxxxxx Subject: EXTERNAL: Re: RE: Re: Feasibility - Squid as user-specific SSL tunnel (poor- Did you try something like http://squidkerbauth.cvs.sourceforge.net/viewvc/squidkerbauth/squid_kerberizer/ ? It is a local proxy which uses the credentials of the logged in user to authenticate to the next proxy (e.g. squid). It is a POC and works on Unix and Windows. Markus "Bucci, David G" <david.g.bucci@xxxxxxxx> wrote in message news:581C2F1AB3315145BD64D2022634BF8D01A6AE5CFA@xxxxxxxxxxxxxxxxxxxxxx > 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 > >
