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

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_at_lmco.com> wrote in message
news:581C2F1AB3315145BD64D2022634BF8D01A6AE5CFA_at_HVXMSP4.us.lmco.com...
> 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_at_treenet.co.nz]
> Sent: Tuesday, August 17, 2010 8:44 PM
> To: Bucci, David G
> Cc: squid-users_at_squid-cache.org
> Subject: 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
>
>
Received on Wed Aug 25 2010 - 18:43:23 MDT