Re: [squid-users] NTLM Authentication and Connection Pinning problem

On Wed, 17 Feb 2010 08:59:27 -0600, Jeff Foster <jfoste_at_gmail.com> wrote:
> I'm not sure which TCP stream you are referencing in your reply.
> If you are looking at client port 1917; I agree with your response.
>

There are 7 distinct TCP streams/connections in that trace.
The first 6 display the exact same behavior or persist long enough to do
the login and object fetch, but the object requires closure.

The 7th does the weird 304 and re-auth required by the server. It also
persists during the entire auth setup sequence, but we never see the end of
the sequence so can't tell if the object kills it as well or not.

The port does not matter here. Both the server and client and Squid are
all working exactly correctly according to the data they transfer.

Lets put it this way....
 If the objects being requested were sent by the server with correct
Content-Length headers. The _entire_ page load (all 7 of those connections)
would happen through a single TCP link.
 This can be seen working in the 304 response (which has a known 0-byte
length) and its followup request re-using the same ports.

 The reality is that the server is sending out objects that range from 0
bytes to infinite, without telling Squid how long they are. There is
exactly one way for it to tell Squid the end of any given object and the
start of the next. To completely close the TCP link.
 There is exactly one way for Squid to pass that information on. To close
the Squid->client TCP link.

Cut off the head the body dies. Cut off the body the head dies. Either way
you look at it the client->squid->server pinned linkage dies.

NP: I think what you were expecting to see was the client->squid link dies
and 'untie' the squid->server link back to re-use as a normal persistent
connection. Then a new client->squid link to tie it up again later. While
that would normally be the case, these are dying due to the unknown-length
objects, and the server link is the first to go down.

> The problem as I see it is the TCP stream for the client port 1919.
> It is using port 37159 on the squid server to the upstream. Then
> in packet 210 the upstream request switches to port 37161.
>
> The trace was run from the initial client request to long after the
> Internet Explorer authentication dialog was displayed.

All of this happens magically in the background away from the users view,
thus its called 'transparent' authentication. Access to pages being
'transparent' from the users view.

Amos

> On Wed, Feb 17, 2010 at 1:50 AM, Amos Jeffries wrote:
>> Jeff Foster wrote:
>>>
>>
>> Hi Jeff,
>>
>> Looking at the 3.1 capture I see everything working perfectly as it
>> should
>> be.
>>
>> The connection is held open as expected of persistent connections
>> through
>> the enire auth sequence and beyond. It finishes with an actual page
>> result
>> starting to come back from the final auth credentials.
>>
>> The thing to notice at this point is that the object being fetched has
>> no
>> Content-Length: header and so the connection MUST end with closure to
>> terminate the file. This will prevent it ever being re-used as you
>> expected.
>> NP: all the object replies this server produces seem to have this type
>> of
>> content preventing connection re-use.
>>
>> At the end it is your client machine which sends a RST packet and
aborts
>> the download and closes the connections before the object is complete,
>> its
>> visibly a partial page in the trace.
>>
>>
>> The only odd thing I can see so far is the followup from the
>> http://simon/Styles/forms.css request. Server replies with a 304
>> redirection
>> (keep alive allows connection re-use :). As expected The client sends
the
>> auth credentials to the new request URL through teh existing
connection.
>> But
>> then the server replies with a brand new auth challenge as if it had
>> never
>> seen the client before.
>> The trace does not continue long enough to follow that, but I would
hope
>> the client re-auths properly and things continue fine. At least until
the
>> next unknown-length object.
>>
>> Amos
>> --
>> Please be using
>> Current Stable Squid 2.7.STABLE8 or 3.0.STABLE24
>> Current Beta Squid 3.1.0.16
>>
Received on Wed Feb 17 2010 - 22:30:15 MST