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

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_at_moeller.plus.com]
Sent: Wednesday, August 25, 2010 2:43 PM
To: squid-users_at_squid-cache.org
Subject: EXTERNAL: Re: RE: Re: [squid-users] 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_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 Thu Aug 26 2010 - 17:35:15 MDT