Re: [squid-users] External ACL Auth & Session DB for 100+ clients behind NAT

On 22/05/2012 6:36 p.m., Nishant Sharma wrote:
> Hi Amos,
>
> Thanks for your detailed response.
>
> On Tue, May 22, 2012 at 4:56 AM, Amos Jeffries wrote:
>>> external_acl_type hosted_auth ttl=0 %SRC /etc/squid/auth.pl
>>> acl loggedin external hosted_auth
>>> deny_info https://hostedserver/auth.html loggedin
>>> http_access deny !loggedin
>>> http_access allow all
>>>
>> Please be ware there is no authentication in this setup, despite the login
>> on your portal page.
>> What you have is session-based *authorization*.
>> It is a razor-thin line, but critical to be aware of. Since NAT erases and
>> plays with the %SRC key which you are using to identify clients. 1) NAT
>> hides unwanted visitors on the POP networks. 2) The XFF workaround to undo
>> the NAT is header based with risks of header forgery. So NAT introduces
>> multiple edge cases where attacks can leak through and hijack sessions.
> I understand the difference between Authentication and Authorization,
> but here the prime motive is to enforce user based access rules and
> perform AuthN / AuthZ over a secured channel against IMAP.
>
> If we segregate the zones as "Trusted" and "Non-Trusted" where the
> trusted zone is our HO and a proxy forwards the requests to our
> publicly hosted squid with XFF header while "Non-Trusted" zones are
> our spokes and roadwarrior users who are behind a simple NAT. Trusted
> zone users are allowed to access the proxy with just authorization
> (session / form based) and Non-Trusted zone users need to authenticate
> compulsorily (explicit proxy-auth). This way, we could enforce the
> policies based on users instead of IPs.
>
> Again, the problem is the secured authentication against IMAPS. Mail
> is hosted on google and we can't use DIGEST that we receive from
> browsers. BASIC auth is ruled out again due to security reasons. VPN /
> Stunnel is not considered due to user credential / machine management.
>
>>> While the HTML file displays a login
>>> form over HTTPS and sends request to a CGI script which authenticates
>>> against IMAPS and populates the DB with session information. I
>>> understand that I can not use cookies for authentication as browser
>>> will not include cookie set by our authentication page for request to
>>> other domains.
>> Correct.
> On some more googling, I found something called "Surrogate Cookies" here:
> https://kb.bluecoat.com/index?page=content&id=KB3407
> https://kb.bluecoat.com/index?page=content&id=KB2877
>
> From what I could understand is their primary usage is with the
> reverse proxy in front of the webservers with limited domains behind
> them but it is being used for surrogate authentication with normal
> proxy deployments by forcing proxies to accept cookies for any domain?
> Even the commercial proxies advise against using surrogate credentials
> wherever possible. The major disadvantage I can see is they can't be
> used with wget, lynx, elinks, java applets etc. which expect usual
> proxy authentication.
>
>> bit lacking in how to merge the format "%SRC %<{X-Forwarded-For}" into one
>> UUID token. There is the space between the two tokens and XFF header is
>> likely to contain spaces internally which the script as published can;t
>> handle.
>> HINT: If anyone has a fix for that *please* let me know. I know its
>> possible, I stumbled on a perl trick ages back that would do it then lost
>> the script that was in :(
> Following snippet should help if you just want to strip spaces in the
> $token string:
>
> my $token = "%SRC %<{X-Forwarded-For}";
> $token =~ s/\ //; # This should remove only the first space
> $token =~ s/\ //g; # This removes all the spaces in the string
>
> If you could send in sample strings - received and final expected
> result, I can help with hacking Perl code.

Thank you. Expected input is strings like:

"1 foo bar" -> channel-ID="1", UUID="foo bar"
"2 hello" -> channel-ID="2", UUID="hello"

Only numerics in the channel-ID, followed by one SP to separate them,
then anything including more SP characters in the UUID portion.

I think my initial was something nasty like explode on S, then strip the
channel-ID followed by space from the original and call the remainder
UUID. Any improvements on that would be great.

>
> I have also written an auth helper based on the existing POP3 auth
> helper. It authenticates against IMAP and IMAPS depending on the
> arguments provided e.g.:
>
> ## IMAPS against google but return ERR if user tries to authenticate
> with @gmail.com
> imap_auth imaps://imap.google.com mygooglehostedmail.com
>
> ## IMAP auth against my own IMAP server
> imap_auth imap://imap.mydomain.com mydomain.com
>
> Where should I submit that as contribution to Squid?

code submission and auditing procedures are detailed at:
http://wiki.squid-cache.org/MergeProcedure

Essentially email a patch or the helper sub-folder to squid-dev at
squid-cache.org with description of what its for. Under our naming
scheme this would be basic_imap_auth.

I'm also asking helper contributors to be willing to support their
helper for a reasonable period (a year or so) here in squid-users to
reduce workload for everyone and get issues fixed faster.

Amos
Received on Sun May 27 2012 - 11:59:13 MDT