Subject: Chained proxies, persistent connections, authentication

From: Rob Maidment <[email-masked]>
Date: Thu, 23 Oct 2003 15:31:36 +0100

I am currently investigating a problem that occurs in this type of scenario:

browser -> proxy1 -> proxy2 -> server

Proxy1 is actually a Squid proxy, it is passing though the end-user
authentication to proxy2.  The problem occurs because proxy1 is reusing
connections to proxy2 for requests from different users, but proxy2 is only
authenticating the first request on each new connection.  This means that
subsequent requests are not being authenticated, and these requests are
being treated as if they originated from the first user to use the
connection.  

Which proxy is at fault?  I understood that one of the intended benefits of
persistent connections was that a proxy would only have to authenticate the
first request on each connection, which is a huge performance benefit.  But
ths assumes that a downstream proxy that passes through user authentication
will not re-use the connection for different users.  Having said that, so
far I have been unable to find any specification that says a proxy need only
authenticate the first request on each connection.

I'd appreciate any thoughts on the matter,

Rob Maidment.

---------------------------------------------------------------------------------------------------------------
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: "Patrick R. McManus" <[email-masked]>
Date: Thu, 23 Oct 2003 10:36:18 -0400

[Rob Maidment: Oct 23 15:31]
> first request on each connection, which is a huge performance benefit.  

proxy2 is at fauilt. HTTP transactions are stateless.

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 23 Oct 2003 16:40:17 +0200

With the http authentication framework, only requests are authenticated  
and
never connections. If a proxy extends authentication to the (persistent)
connection, it introduces a security hole such as you observed.

//Stefan

Am Donnerstag, 23.10.03, um 16:31 Uhr (Europe/Berlin) schrieb Rob  
Maidment:

> authentication to proxy2.  The problem occurs because proxy1 is  
> reusing connections to proxy2 for requests from different users, but  
> proxy2 is only authenticating the first request on each new  
> connection.  This means that subsequent requests are not being  
> authenticated, and these requests are being treated as if they  
> originated from the first user to use the connection. 
>
> Which proxy is at fault?  I understood that one of the intended  
> benefits of persistent connections was that a proxy would only have to  
> authenticate the first request on each connection, which is a huge  
> performance benefit.  But ths assumes that a downstream proxy that  
> passes through user authentication will not re-use the connection for  
> different users.  Having said that, so far I have been unable to find  
> any specification that says a proxy need only authenticate the first  
> request on each connection.
>
> 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.

---

From: Dave Kristol <[email-masked]>
Date: Thu, 23 Oct 2003 11:34:25 -0400 (EDT)

Rob Maidment wrote:
> connections to proxy2 for requests from different users, but proxy2 is 
> only authenticating the first request on each new connection.  This 
> means that subsequent requests are not being authenticated, and these 
> requests are being treated as if they originated from the first user to 
> use the connection. 
> 
> Which proxy is at fault?  I understood that one of the intended benefits 
> of persistent connections was that a proxy would only have to 

IMO, proxy1 is at fault.  Proxy-authenticate is a hop-by-hop header.  Proxy1 can 
authenticate itself to proxy2, but the browser cannot (according to the 
standard) authenticate *itself* to proxy2, only to proxy1.  If the 
authentication adhered to that rule, the persistent connection between proxies 1 
and 2 would be managed correctly.

Dave Kristol

---

From: "Scott Lawrence" <[email-masked]>
Date: Thu, 23 Oct 2003 12:57:46 -0400 (EDT)

> requests are being treated as if they originated from the first user to

You're not clear on what's happening here - what authentication header
is proxy2 interpreting?  As a proxy, it should not be using the Authorization
header at all - that is for 'server', not any proxy.

As Dave pointed out, proxy1 should not be passing through any
Proxy-Authorization header because that is a hop-by-hop header; if
proxy2 is challenging by sending a 407, then only proxy1 can respond to
that challenge (not intuitive, and perhaps not optimal, but that is
what the standard says).

In any event, proxy2 is incorrect to associate the connection with
the authentication of the first request on that connection; all requests
are stateless, including authentication attributes.  Each request must
be authenticated on its own - this is _not_ one of the _actual_ benefits
of persistent connections.

---

From: David Morris <[email-masked]>
Date: Thu, 23 Oct 2003 09:54:30 -0700 (PDT)

> of persistent connections.

I don't recall how it was determinted that Proxy1 was forwarding proxy
authentication headers to Proxy2. Sans a tcp/ip trace or comprehensive
logs, I would postulate that the described behavior would occur with both
proxy1  and proxy2 working as Dave and Scott have described is required:

a.  User1 sends request to Proxy1 and proxy authenticates with Proxy1
which User1 is authorized to do.
b.  Proxy1 sends the request to Proxy2 and subsequently authenticates
itself (proxy1) to Proxy2.
c.  User1 gets the expected response from Server via the proxy chain.

d.  User2 sends request to Proxy2 and proxy authenticates with Proxy1
which User2 IS authorized to use.
e.  Proxy1 now sends the request to Proxy2 and Proxy1 validly
authenticates with Proxy2 ... proxy1 is still a valid user of proxy2.
f.  User2 gets the unexpected response from Server but it is valid.

This scenario would appear, to someone who was expecting users and not
proxies to authenticate with proxy2, as if proxy2 was remembering stale
data.

Just a thought,
  Dave Morris

---

From: Duane Wessels <[email-masked]>
Date: Thu, 23 Oct 2003 14:50:10 -0600 (MDT)

> authentication headers to Proxy2. Sans a tcp/ip trace or comprehensive

FYI, this is a feature of Squid.  An admin can configure Squid to
forward the Proxy-Authorization header (without consuming it).

I would suggest that in this particular case, since both Squid and
"proxy2" are breaking the rules, the problem is solvable by disabling
server-side persistent connections in Squid.

Duane W.

---

From: Robert Collins <[email-masked]>
Date: Fri, 24 Oct 2003 19:06:26 +1000

> server-side persistent connections in Squid.

Finally got time to contribute to the thread. Firstly, rfc 2616 14.34
allows squids behaviour in forwarding the authentication details.

The ntlm/kerberos tcp session based authentication used by MS proxies
(and squid has an option in 2.5 and above) isn't compatible with the
base HTTP spec. However there is an expired I-D (one url for it is 
http://216.239.57.104/search?q=cache:Fcb67r9QFF4J:www.globecom.net/ietf/draft/draft-brezak-spnego-http-03.html+SPNEGO+http+draft&hl=en&ie=UTF-8)
the draft was brezak-spnego-http.

That draft described a new header "Proxy-support:
Session-Based-Authentication" for proxies to use to indicate to clients
that they support the connection semantics needed to operate correctly
with such upstream servers (proxies where not documented, but we've
found MSIE uses the same mechanism with proxies as servers, insofar as
the authentication is concerned - we haven't tested the proxy-support
header.

Squid doesn't issue the Proxy-support header, and if (as it should be)
it's listed in the connection header by the upstream proxy, then squid
would strip it. However, as we don't support the connection semantics to
use NTLM or kerberos through squid, in recent squid 2.5 releases we
filter the incompatible authentication headers.

So, I'd suggest that the user has an older squid release, as a newer
release wouldn't show these symptoms.

Rob

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