W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2003

Re: Chained proxies, persistent connections, authentication

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Thu, 23 Oct 2003 16:40:17 +0200
Cc: "'ietf-http-wg@w3.org'" <ietf-http-wg@w3.org>
To: Rob Maidment <rob.maidment@clearswift.com>
Message-Id: <D1D177B6-0566-11D8-85ED-00039384827E@greenbytes.de>

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:

>
>
> 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 support@clearswift.com 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.
Received on Thursday, 23 October 2003 10:40:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:25 GMT