Re: [squid-users] Question about "proxy_auth REQUIRED" and the case of flushing the authentication-cache

On 21/02/2013 9:47 p.m., Tom Tom wrote:
> Hi
>
> With squid 3.2.7, I have the following curiosity:
>
> SCENARIO 1
> <<squid.conf>>
> acl AUTHENTICATED proxy_auth REQUIRED
> external_acl_type SQUID_KERB_LDAP ttl=7200 children-max=20
> children-startup=5 children-idle=1 negative_ttl=7200 %LOGIN
> /usr/local/squid/libexec/ext_kerberos_ldap_group_acl -g "XXX"
> acl INTERNET_ACCESS external SQUID_KERB_LDAP
> ...
> ...
> http_access deny !INTERNET_ACCESS
> http_access deny !AUTHENTICATED
> http_access allow INTERNET_ACCESS AUTHENTICATED
> http_access deny all
>
> With the config above, I have the following lines in the access.log:
> [Thu Feb 21 06:56:45 2013].167 38 XXX TCP_REFRESH_UNMODIFIED/304
> 332 GET http://imagesrv.adition.com/banners/750/683036/dummy.gif USER
> FIRSTUP_PARENT/XXX image/gif
> [Thu Feb 21 06:57:04 2013].621 38 XXX TCP_REFRESH_UNMODIFIED/304
> 261 GET http://imagesrv.adition.com/banners/750/683036/dummy.gif USER
> FIRSTUP_PARENT/XXX image/gif

Note that both INTERNET_ACCESS and AUTHENTICATED access controls
require authentication credentials in order to match. Both will generate
authentication challenges if there are no credentials.

Without a cache.log trace showing all the auth oeprations (level 9 debug
woudl be best) I can't say why the first request

> ----------------------------------------------------
>
> SCENARIO 2
> <<squid.conf (without proxy_auth REQUIRED)>>
> external_acl_type SQUID_KERB_LDAP ttl=7200 children-max=20
> children-startup=5 children-idle=1 negative_ttl=7200 %LOGIN
> /usr/local/squid/libexec/ext_kerberos_ldap_group_acl -g "XXX"
> acl INTERNET_ACCESS external SQUID_KERB_LDAP
> ...
> ...
> http_access deny !INTERNET_ACCESS
> http_access allow INTERNET_ACCESS
> http_access deny all
>
>
> Now, the same request looks like this:
> [Thu Feb 21 06:55:59 2013].086 0 XXX TCP_DENIED/407 4153 GET
> http://imagesrv.adition.com/banners/750/683036/dummy.gif - HIER_NONE/-
> text/html
> [Thu Feb 21 06:55:59 2013].135 44 XXX TCP_REFRESH_UNMODIFIED/304
> 332 GET http://imagesrv.adition.com/banners/750/683036/dummy.gif USER
> FIRSTUP_PARENT/XXX image/gif
>
> A tcpdump shows, that the "authorization"-header is not sent in the
> first request. In scenario 2, the authorization-header is sent after
> the TCP_DENIED/407 response from squid (normal behavior). In scenario
> 1, squid response directly with 304.
>
> What is the influence of "AUTHENTICATED" in the first example, not to
> re-authenticate the request? Why does squid needs to re-authenticate
> (TCP_DENIED/407) without the "AUTHENTICATED" tag in the "http_access"
> line (Scenario 2)? Is it possible, that with the "AUTHENTICATED" tag
> squid uses the authentication-cache? And without the "AUTHENTICATED"
> tag, squid will not use the authentication-cache or flushes the
> cache-entry for every request?

No. Kerberos does not make use of the username cache for validation. It
only adds recently tested credentials to the cache for reporting purposes.

Kerberos credentials are tied to the TCP connection state details and
may be accepted if the new requests proxy-auth token matches the one
tied to the connection already. The first request on a connectio should
almost always be a DENIED/407, unless the Kerberos client is deciding to
send its keytab token on the first request fof a connection - in which
case Squid may be validating and accepting it immediately.

Squid of any version _in general_ should be consistently behaving as per
scenario #2, except in the situations where scenario #1 is possible. But
that exception is client dependent and should not be related to the
squid.conf change you describe.
Due to that exception case(s) it is hard to answer your question about
"why" without seeing a debug ALL,9 cache.log trace of these tests. Can
you supply that please?

>
> I have other squids running (3.1.20), which are configured like
> scenario 2, but behaves like scenario 1. Why does squid 3.1.20 act
> different as 3.2.7?

Squid-3.1 has many authentication credentials management bugs that got
fixed under the bug 2305 project. Including things like credentials from
user-A being reported and shared by user-B - which sounds like scenario #1.

> With "debug_options 29,9" (see below) in squid 3.2.7, I see that in
> the "wrong case" (without the AUTHENTICATED tag on the http_access
> line), squid is "freeing request 0x1646830".

HttpRequest or Auth::UserRequest request?

> When I request the same
> file again, then squid response first with a "TCP_DENIED/407". Does
> the "freeing" means, that squid "flushes" his authentication-cache and
> therefore need to re-authenticate this request everytime?
> 2013/02/21 08:43:58.583 kid1| UserRequest.cc(506) addReplyAuthHeader:
> headertype:76 authuser:0x1646830*3
> 2013/02/21 08:43:58.583 kid1| UserRequest.cc(126) releaseAuthServer:
> No Negotiate auth server to release.
> 2013/02/21 08:43:58.583 kid1| UserRequest.cc(125) ~UserRequest:
> freeing request 0x1646830
>
> I can also see, that in the wrong case (re-authenticate), squid
> flushes his cache and make for the same request a new entry with a new
> TTL:
> $ squidclient mgr:username_cache
> HTTP/1.1 200 OK
> Server: squid
> Mime-Version: 1.0
> Date: Thu, 21 Feb 2013 08:36:14 GMT
> Content-Type: text/plain
> Expires: Thu, 21 Feb 2013 08:36:14 GMT
> Last-Modified: Thu, 21 Feb 2013 08:36:14 GMT
> X-Cache: MISS from XXX
> Via: 1.1 XXX (squid)
> Connection: close
>
> Cached Usernames: 1 of 7921
> Next Garbage Collection in 35 seconds.
>
> Type State Check TTL Cache TTL Username
> --------------- --------- --------- --------- ------------------------------
> AUTH_NEGOTIATE Ok -1 3600 USER
>
>
>
> In the "good case", squid does not throw away the cache-entry and the
> TTL is decrementing (even after I make new requests) -> expected
> behavior.
>
> So, why does squid flushes the authentication-cache for every request,
> when I use "http_access allow INTERNET_ACCESS" (without the tag
> AUTHENTICATED)? And why does squid 3.1.20 behaves different? Probably
> a bug?

Yes probably a bug. The cache management on Negotiate and NTLM auth is a
little screwed up by the credentials primarily being tied to the TCP
connection instead of the username cache. So garbage collection of the
cache can remove them even while they are still in use, or the cache can
list them even after the TCP connection has died.

Amos
Received on Thu Feb 21 2013 - 21:55:11 MST