[squid-users] Pages sometimes load as a mess of random (?) symbols

[Amos Jeffries]

On 05/10/17 22:32, Grey wrote:
> Firstly, thanks a lot for taking the time to check my configuration and
> provide such detailed suggestions; I think I've followed all of them and
> fixed the problems you pointed out.
> We have a Windows domain and all those "all" directives where inherited from
> our old proxy server (running Squid verson 3.1.20) and were used to let
> domain users not receive any popups asking for credentials, while at the
> same time presenting those credentials requests to non-domain users; if I'm
> understanding your comments correctly I can safely remove them and get the
> same result, am I right?

Most of the 'all' uses were pointless even in the old config. Only the 
ones on the lines with AUTH and ProxyUsers ACLs had any effect on popups.


As for your requirement;

If you think about it Squid has zero ways to identify on-domain vs 
off-domain users until *after* the user has logged in. Any on-domain 
user who sends invalid or no credentials is indistinguishable from a 
off-domain user sending invalid or no credentials.

So the config hack did not actually do what you were wanting in the 
first place. It just suppresses login challenges for *everybody* without 
credentials - as it was designed to do.


Popups are a feature of the client agent being used (aka Browser). The 
browser may choose to do it at any time for any reason, though the 
popular ones usually only do so if it cannot automatically locate any 
credentials to send in response to a challenge.

Whatever was working was due to some other behaviour which may change at 
any time regardless of the all hack use. Mostly likely by on-domain 
clients sending their credentials up front before any need was mentioned 
by the proxy.

FYI: The clients sending their users credentials without a challenge is 
*very bad* security practice since they will broadcast those credentials 
to anything they connect, not just your proxy.


> We were having an issue with authentication too, where domain users
> sometimes received a popup asking for credentials (shouldn't happen since I
> have only enabled kerberos auth) and would need to click "Cancel" and reload
> the page to resume browsing correctly; could the presence of all those "all"
> directives have caused that too in your opinion?


The all-hack was preventing Squid from telling the browser what it 
needed to login. So the popups themselves were caused by some other 
reason unrelated to Squid.

That said, the absence of proper instructions from Squid probably was 
involved with the horrible need to cancel and reload the page. The 
normal behaviour would have been either silent re-try with other 
automatic credentials or a popup that user could login with successfully.


FWIW: It is true that Kerberos tends to have popups less often than 
NTLM. But that is just a side-effect of Kerberos being far more 
efficient and less fragile than NTLM with its relatively static keytab 
value - the NTLM equivalent of keytab is generated fresh on every single 
TCP connection with a client connection to the DC, which takes up time 
and can be interfered with. So the chance of problems leading to a popup 
in Kerberos are far lower, but not gone completely.



> 
> The new configuration should result in this if I didn't miss/misunderstand
> anything (I've addedd a whitelist rule that I missed earlier):
> 
> ### TESTSQUID1 ###
> 
> http_port 3128
> dns_v4_first on
> pinger_enable off
> netdb_filename none
> 
> error_default_language it
> cache_mgr helpdesk at test.it
> 
> acl SSL_ports port 443
> acl Safe_ports port 80		# http
> acl Safe_ports port 21		# ftp
> acl Safe_ports port 443		# https
> acl Safe_ports port 70		# gopher
> acl Safe_ports port 210		# wais
> acl Safe_ports port 1025-65535	# unregistered ports
> acl Safe_ports port 280		# http-mgmt
> acl Safe_ports port 488		# gss-http
> acl Safe_ports port 591		# filemaker
> acl Safe_ports port 777		# multiling http
> acl CONNECT method CONNECT
> 
> auth_param negotiate program /usr/lib/squid/negotiate_kerberos_auth -r -d
> auth_param negotiate children 150
> auth_param negotiate children 150 startup=20 idle=10
> auth_param negotiate keep_alive on
> 
> external_acl_type ProxyUser children-max=75 %LOGIN
> /usr/lib/squid/ext_kerberos_ldap_group_acl -g INTERNET at TEST.LOCAL -D
> TEST.LOCAL -S testldap
> acl ProxyUser external ProxyUser
> 
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> http_access allow localhost
> http_access deny manager
> 
> acl destsquid dstdomain .testsquid1 .testsquid2
> http_access allow destsquid
> 
> acl siti_whitelist dstdomain "/etc/squid/siti_whitelist"
> 

It should be obvious, but just so that it is clearly stated:

Anything which is allowed or denied regardless of user auth (eg the 
whitelist?) should be done in an http_access line above the "deny !AUTH" 
line.


> acl AUTH proxy_auth REQUIRED
> http_access deny !AUTH
> 
> http_access allow siti_whitelist
> http_access allow ProxyUser

If you get unwanted popups after this config update, you can try adding 
the all-hack back onto the above line.

> http_access deny all
> 
> icap_enable on
> icap_send_client_ip on
> icap_send_client_username on
> icap_client_username_encode off
> icap_client_username_header X-Authenticated-User
> icap_preview_enable on
> icap_preview_size 1024
> icap_service service_req reqmod_precache bypass=1
> icap://testicap:1344/REQ-Service
> adaptation_access service_req allow all
> icap_service service_resp respmod_precache bypass=0
> icap://testicap:1344/resp
> adaptation_access service_resp allow all
> 
> coredump_dir /var/spool/squid
> 
> refresh_pattern ^ftp:		1440	20%	10080
> refresh_pattern ^gopher:	1440	0%	1440
> refresh_pattern -i (/cgi-bin/|\?) 0	0%	0
> refresh_pattern .		0	20%	4320
> 
> Getting back to the main problem, i've set "icap_enable off" and reloaded
> Squid, then tried again and got the same problem; since we're not using any
> cache parent and Squid isn't using ICAP at the moment, can I assume there's
> nothing else I can do and just have to ignore the problem?
> The thing that bugs me is that only Chrome seems to be having this
> particular problem... could this even be something linked to a bug or a
> simple behaviour difference between Chrome and IE/Firefox?
> Thanks again for all your patience :)

There is one other thing you can do. That is to enable "debug_options 
11,2" for a while and run a test fetching with both browsers.

Squid-3.5 with that debug setting should log the HTTP request headers in 
their on-wire format so you can compare what is going on in both client 
and server connections for both browsers vs what the browsers think they 
received.

That might give you some clues about things to workaround it. Just make 
sure that workarounds are done as conservatively as possible so as not 
to break other sites in other annoying ways.

Amos