[squid-users] can't explain 403 denied for authenticated user

[Amos Jeffries]

On 25/05/24 07:28, Kevin wrote:
> Hi,
> 
> We have 2 external ACLs that take a request's data (IP, authenticated 
> username, URL, user-agent, etc) and uses that information to determine 
> whether a user or host should be permitted to access that URL.   It 
> almost always works well, but we have a recurring occasional issue that 
> I can't figure out.
> 
> When it occurs, it's always around 4AM.   This particular request occurs 
> often - averages about once a second throughout the day.
> 
> What we see is a "403 forbidden" for a (should be) permitted site from 
> an authenticated user from the same IP/user and to the same site that 
> gets a "202 connection established" every other time.

Is maybe 4am the time when your auth system refreshes all nonce?
  - thus making any currently in-use by the clients invalid until they 
re-auth. You might see a mix of 403/401/407 in a bunch at such times.


Or maybe in a similar style one/some of the clients is broken and fails 
to update its nonce before it expires at 4am?
  - looking at which client agent and IP were getting the 403 and/or the 
nonce which received 403 will give you hints about this possibility.


Or your network router(s) do garbage collection and terminate 
long-running connections to free up TCP resources?
  - thus forcing a lot of client re-connects at 4am, which may:
  a) overload the auth system/helper, or
  b) break a transaction that included nonce update for clients - 
resulting in their next request being invalid nonce.


Or maybe you have log processing software that does "squid -k restart" 
instead of the proper "squid -k rotate" to get access to the log files?

Or maybe your auth system has a limit on how large nonce-count can become?
  - I notice that the working request has 0x2F uses and the forbidden 
has 0x35 (suspiciously close to 50 in decimal)




> 
> The difference I see in the logs:  though all the digest auth info looks 
> okay, the %un field in the log for the usual (successful) request is the 
> authenticated username, while in the failed request, it's "-".   So 
> though there hasn't been an authentication error or "authentication 
> required" in the log - and the username is in the authentication details 
> in the log entry -  it seems like squid isn't recognizing that username 
> as %un.


Be aware that a properly behaving client will *not* send credentials 
until they are requested, after which it should *always* send 
credentials on that same connection (even if they are not requested 
explicitly).

That means some requests on a multiplex/pipeline/keep-alive connection 
MAY arrive with credentials and be accepted(2xx)/denied(403) without 
authentication having occured. Entirely due to your *_access directives 
sequence. In these cases the log will show auth headers but no value for 
%un and/or %ul.


> 
> My squid.conf first tests a request to see if an unauthenticated request 
> from a particular host is permitted.  That external ACL doesn't take a 
> username as an argument.   If that external ACL passes, the request is 
> allowed.
> 

Please *show* the config lines rather than describing what you *think* 
they do. Their exact ordering matters *a lot*.

  Obfuscation of sensitive details is okay/expected so long as you makes 
it easy for us to tell that value A and value B are different.


FWIW; if your config file is *actually* containing only what you 
described it is missing a number of things necessary to have a safe and 
secure proxy. A look at your full config (without comments or empty 
lines) will help us point out any unnoticed issues for you to consider 
fixing.


> The next line in squid.conf is
> 
> acl auth_users proxy_auth REQUIRED
> 

FYI the above just means that Squid is using authentication. It says 
nothing about when the authentication will be (or not be) performed.


> ... and after that, the external ACL that takes the username as well as 
> the other info.
> 


HTH
Amos