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