Subject: RE: Chained proxies, persistent connections, authentication

From: Rob Maidment <[email-masked]>
Date: Fri, 24 Oct 2003 11:10:31 +0100

Thankyou for all the contributions on this thread.  

I over-simplified the proxy1 (Squid) role in the scenario slightly for the
sake of clarity, so I'll explain exactly what is going on:  Squid is
authenticating the users, using the Basic authentication scheme I assume.
It then consollidates these users into 5 roles-based groups.  When Squid is
asked to authenticate with the upstream proxy (proxy2), it responds with one
of 5 user IDs, to indicate which group the user falls into.  Proxy2 then
applies a security policy based on the group.  So proxy1 is not literally
passing through the end-user authentication; it is responding to upstream
authentication differently depending on which user is making the request.

The problem occurs because proxy1 re-uses persistent connections to proxy2
for users in different groups, and proxy2 only authenticates the first
request on each connection.  So subsequent requests may have the wrong
security policy applied.

Thanks to your responses, I now realise proxy2 is at fault since it is
individual requests that should be authenticated, not connections.  I've
also learnt there may be a workaround by disabling server-side persistent
connections in Squid.

As a matter of interest, if the roles were reversed would Squid authenticate
every request, or only the first request on each connection?  

Thanks again,
Rob.

---------------------------------------------------------------------------------------------------------------
Clearswift monitors, controls and protects all its messaging traffic in 
compliance with its corporate email policy using Clearswift products. 
Find out more about Clearswift, its solutions and services at 
www.clearswift.com.
***********************************************************************************
This communication is confidential and may contain privileged 
information intended solely for the named addressee(s). It may not 
be used or disclosed except for the purpose for which it has been 
sent. If you are not the intended recipient, you must not copy, 
distribute or take any action in reliance on it. Unless expressly stated, 
opinions in this message are those of the individual sender and not of 
Clearswift. If you have received this communication in error, please 
notify Clearswift by emailing [email-masked] quoting the 
sender and delete the message and any attached documents. Clearswift accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Clearswift domain.
This footnote confirms that this email message has been swept by 
MIMEsweeper for Content Security threats, including computer viruses.

---

From: Robert Collins <[email-masked]>
Date: Fri, 24 Oct 2003 20:59:14 +1000

> authenticating the users, using the Basic authentication scheme I assume.

That depends on your squid version and config. If you are running 2.5,
it could be any of basic, rfc2617 digest, or NTLM.

> request on each connection.  So subsequent requests may have the wrong

That sounds like a real bug in proxy2. Duanes suggestion of disabling
server persistent connections is an effective workaround. proxy2
however, should be fixed. The MS NTLM/Kerberos/Negotiate connection
based authentication do connection based auth, but AFAIK MS's basic
implementation does check per request. I don't think you've specified
which software proxy2 was, I assumed it was an MS proxy due to the use
of connection orientated semantics....

> every request, or only the first request on each connection?  

Every request for basic and digest authentication. Once per connection
for NTLM authentication.

Rob
-- 
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.