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
