On Monday 03 March 2003 01.27, Gary Price \(ICT\) wrote:
> So my questions are
> - is this really doing what it appears to be doing?
Yes, as long as there is no pipelined connections.
> - why does this appear to give no problems?
Because there is sufficient gap between the requests to keep the 1-1
relation, and your browser does not reuse the same client port number
too quickly.
> - how can I stress it, so it displays whatever weaknesses it might
> have?
Stressing this without a NTLM capable tool other than your browser is
a bit hard..
1. Send two requests on the same connection without waiting for the
reply.
but some can be shown..
2. Have a client not aware of persistent conenctions repeatedly
request an object as fast as it can while forcing a cache bypass and
keep an eye on the number of connections opened to the origin server.
> - for the change I have made, are there any other parts of
> squid that need to be altered?
Yes.
You need to at a minimum disable the processing of pipelined requests
also..
> - does my change have significant performance implications?
Yes.
Yor change completely invalidates the connection sharing among client
connections which is an important and wanted aspect.
Also you allow for another client to reuse the server connection after
the current client is done, simply by opening a new connection from
the same IP address and port and thereby steal the previous clients
authorization at the server. Such things can happen on any multiuser
station such as Terminal Server.
You also get into trouble if the server (or Squid) chooses to close
the server connection. This will make Squid open a new connection on
the next request which will then require the client to authenticate
himself, and as the client thinks it is already successfully
authenticated it will assume the current user credentials is not
valid for this request and give a login box..
Basically you have a good solution to the problem but implemented the
wrong place in Squid.
The Problem: Connection oriented authentication requires end-to-end
connection orientation, not the hop-by-hop connection orientation
mandated by the HTTP RFC.
What should be done is that if you detect a Authorization header of
type NTLM or NEGOTIATE then the client connection needs to be flagged
as using connection oriented authentication, and from that point on
* Any requests on that client connection must use the same server
connection
* Squid may not even dream of reusing the same server connection for
another client connection, even if it happens to have the same
ip:port.
* When the server connection is closed, so must the client
connection after sending the current reply (if any).
* When the client connection is closed, so should the server
connection
* As there may only be a single server connection for this client
connection you must stop processing pipelined requests on that client
connection.
This is best addressed by making a tight relation between the
connections, and not consider the connection for reuse in the pconn
pool but direclty based on the client filedescriptor.
I do not remember enough of Squid-2.3 to guide you on where to do
these changes as I have not looked at this Squid version in many
years, but would happily help you in where/how to solve this in the
current Squid sources (what will become Squid-3.0).
Regards
Henrik
Received on Mon Mar 03 2003 - 02:48:29 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:19:23 MST