Re: problems with the squid-2.5 connection pinning

fre 2006-04-14 klockan 17:07 +0800 skrev Adrian Chadd:

> Was anything ever written to define/clarify the semantics of connection
> pinning (at least for NTLM authentication) ? I couldn't find anything
> with a quick browse with google defining the behaviour (so I could
> see how the error condition should be handled.)
>
> Let me know when you have something and I'll test it out.

It's vaguely defined by the Kerberos/Negotiate I-D by Microsoft, the
rest has to be deduced from NTLM authentication and HTTP specifications
on persistent connections..

What the I-D says (draft-jaganathan-kerberos-http-01.txt):

   If an HTTP proxy is used between the client and server, it must take
   care to not share authenticated connections between different
   authenticated clients to the same server. If this is not honored,
   then the server can easily lose track of security context
   associations. A proxy that correctly honors client to server
   authentication integrity will supply the "Proxy-support: Session-
   Based-Authentication" HTTP header to the client in HTTP responses
   from the proxy. The client MUST NOT utilize the SPNEGO HTTP
   authentication mechanism through a proxy unless the proxy supplies
   this header with the "401 Unauthorized" response from the server.

My comments:

Connection pinning is to support end-to-end connection relations as
required by NTLM and Negotiate. Once the connections are pinned they
enter a very close relation. The prime requirement is that requests must
not be sent on another server connection, and other client requests must
not be sent on this server connection. This due to the Microsoft design
bug that NTLM/Negotiate authentication being tied to the TCP connection,
not the request as such..

If the server connection is gone we have little choice but to close the
client connection as well. This due to the client considering that
connection already authenticated and sending a new authentication
challenge on the same client connection would be considered by the
client as "access denied for this user, ask the user if he has another
login which might be granted access to the requested object".

On persistent connection error conditions such as when the server closes
the connection while we attempt to forward the next request it's best to
do the same on the client to make things behave more like when no proxy
is being used. Technically the HTTP specs says we should send an error
message if acting as a proxy and not being able to forward the request
for some reason (which this could count as), but the tricky part is that
it can not really be expected clients know what to do with that error so
I prefer to see pinned connections as more like tunnels via the proxy
even if we still do full protocol parsing and even caching of public
content.

Regards
Henrik