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

RFC 2616 states that "304 Not Modified" responses don't have a body.

To quote from http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

"If the client has performed a conditional GET request and access is
 allowed, but the document has not been modified, the server SHOULD
 respond with this status code. The 304 response MUST NOT contain a
 message-body, and thus is always terminated by the first empty line after
 the header fields."

In addition the responses include a "Connection: keep-alive" header so
the socket shouldn't be closed and should be ready for re-use after the
http header is received.

These link state that NTLM authentication is TCP connection based
and authentication is not required after the first HTTP request.

http://www.innovation.ch/personal/ronald/ntlm.html
http://curl.haxx.se/rfc/ntlm.html#ntlmHttpAuthentication

Jeff F>

On Wed, Feb 17, 2010 at 4:30 PM, Amos Jeffries wrote:
> On Wed, 17 Feb 2010 08:59:27 -0600, Jeff Foster 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 Thu Feb 18 2010 - 11:45:02 MST