Re: [squid-users] Authorisation fails sometimes

On 17/02/2012 1:31 a.m., Günter Merz wrote:
> > > I tested if an earlier ACL might prevent those transfers from being
> > > allowed by inserting an ACL right before the external_acl_type to
> > > allow all transfers from the host I was using. This didn't show any
> > > TCP_DENIEDs.
> >
> > Um, of course not. "allow all" will never deny anything. Absolutely
> > anything is permitted.
>
> I understand that. What I wanted to see was if any rule _before_ my
> external_acl_type rule could be the reason for my sparse TCP_DENIEDs.
> I proved to myself that that isn't the case.
>
> > > Can anyone think of a reason for this behaviour or another way to
> > > debug for the cause?
> >
> > Beyond seeing "TCP_DENIED" when the credentials are missing, What makes
> > you think there is a fault?
>
> That's the thing. The credentials shouldn't be missing. As far as I
> understand the browser should send the credentials with each request
> and I should see the credentials in each line of the access.log file.
>
> But that's not the case.
>
> Example:
> I'm loading 'http://wordpress.com' (I'm substituting the real user and
> domain names by 'user_at_DOMAIN'):
>
> There will be quite a few GETs like these (everything fine):
> 1329123214.597 35 192.168.0.15 TCP_MISS/200 29688 GET
> http://s2.wp.com/imgpress? user@DOMAIN DIRECT/93.184.220.20 image/jpeg
>
> Then one like these (there's a '-' where 'user_at_DOMAIN' should be):
> 1329123214.605 339 192.168.0.15 TCP_DENIED/407 3899 GET
> http://i.kissmetrics.com/i.js - NONE/- text/html

Ah, kissmetrics Evercookie.

>
> A few lines down the request passes like this (fine again, but I
> presume slow):
> 1329123215.156 239 192.168.0.15 TCP_MISS/200 515 GET
> http://i.kissmetrics.com/i.js user@DOMAIN DIRECT/174.129.203.253
> application/x-javascript
>

If you consider 239 milliseconds slow. The auth re-handshake there took
1.7 seconds from start to finish though.

> Writing about it, I'm starting to think:
> Could this be part of a negotiation?

Yes, this is the credentials being negotiated. You need to go right down
to the packet level to determine whether this was a re-negotiation on a
previously "authenticated" TCP connection (problem), or a new connection
and the browser just omitted the credentials. They are not actually
supposed to send credentials until asked, so the first request on a new
connnection should display exactly like that as a good negotiation
handshake. The pipelined requests after the end of the handshake are the
ones which should consistently have credentials attached. This is why
persistent connections is a minimum requirement for NTLM and Kerberos auth.

> squid is version 3.1.16
> firefox: 10.0.1
> chromium: 17.0.963.46
> squid_kerb_ldap: 1.2.1a

Amos
Received on Thu Feb 16 2012 - 22:15:07 MST