On 15/04/2013 7:22 p.m., Brett Lymn wrote:
I have just updated our proxies to squid 3.3.2 running on rhel 5.8, mostly this went smoothly apart from some access to https. As a rule our proxies authenticate users using kerberos but there some "special" sites that are allowed access to without authentication. When accessing a https site without authentication I see this in the cache.log: 2013/04/15 15:49:51 kid1| WARNING: never_direct resulted in AUTH_REQUIRED. Username ACLs are not reliable here. This causes the never_direct to fail but only for https - this causes cache parent selection to fail which results in the https connection failing. The never_direct that squid is complaining about is this: never_direct allow user_rewrite The ACL user_rewrite is this: external_acl_type user_rewrite_type children-max=60 children-startup=20 ttl=900 %LOGIN /opt/local/squid/libexec/user_rewrite.pl acl user_rewrite external user_rewrite_type The user_rewrite.pl script just strips off the ntlm/kerberos bits in front of the username so the upstream "security" device sees a username it understands. I put the ACL on the never_direct because it is a "slow" ACL evaluation and fires the rewrite in a, supposedly, harmless manner.
Not sure why only https is affected, everything did work with squid 3.1.19.
Probably not just HTTPS. The warning will occur on any request being passed to this ACL without authentication credentials. The result you are getting is telling you that the request is *not* authenticated which the config file is assuming.
The %LOGIN format code requires authentication credentials in order to do the helper lookup. never_direct is not a suitable place to be performing auth challenge responses, so the warning is displayed instead of triggering the auth sequence.
I can work around this by putting a bunch of never_direct deny statements for all the acl's that permit access without authentication but this is a bit tedious.
If you auth-bypass any traffic in http_access you need to do it consistently in all the other places of your config you are relying on credentials. Like these never_direct rules.
The best solution would probably be to place this ACL on the http_access line where you are accepting auth credentials.
Amos
