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@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@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
