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

"Bucci, David G" <david.g.bucci_at_lmco.com> wrote in message
news:581C2F1AB3315145BD64D2022634BF8D01A6B88764_at_HVXMSP4.us.lmco.com...
> 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?
>

Yes it just adds a SPNEGO/Kerberos token to each request using SSPI.

> -----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 - 18:43:29 MDT