W3C home > Mailing lists > Public > www-talk@w3.org > July to August 1996

Re: Proxy authentication -Reply

From: <S.N.Brodie@ecs.soton.ac.uk>
Date: Wed, 10 Jul 1996 22:13:09 +0100 (BST)
Message-Id: <20468.9607102113@strachey.ecs.soton.ac.uk>
To: J.P.Knight@lut.ac.uk (Jon Knight)
Cc: S.N.Brodie@ecs.soton.ac.uk, jwilde@westpub.com, www-talk@w3.org
Jon Knight wrote:
> 
> On Wed, 10 Jul 1996 S.N.Brodie@ecs.soton.ac.uk wrote:
> > However, if I now go my university home page
> > (http://www.soton.ac.uk/) then I am going to get back:
> > 
> > HTTP/1.0 401 Unauthorized to access the document
> > MIME-Version: 1.0
> > Server: CERN/3.0
> > Date: Wednesday, 10-Jul-96 14:42:52 GMT
> > Content-Type: text/html
> > Content-Length: 209
> > WWW-Authenticate: Basic realm="ProxyWorldWide"
> > 
> > (with a different date(!)).  Are you saying that the browser's response
> > to this should be to repeat the same authentication string as it did
> > before?
> 
> Well why not?  The authentication demand is coming from the same server 
> after all - its orginating from the proxy, not the remote target server.

Come on!  The authentication required by a 401 response MUST refer to the
origin server, not to the proxy.  Browsers will (except MS-IE allegedly)
cache the authentication information together with the origin server &
path.  The proxy should not be interfering.

What if I decide to add the target domain to my "no proxy" list?  

Would you, if you were a user of the above proxy, be happy if you
suddenly accessed my server(not via the proxy) which I had built to
request authentication in realm "ProxyWorldWide", and your browser sent me
your authentication details.

> The remote target server should never see this authentication string.
> And note that the proxy server is claiming to be HTTP/1.0 which as you said 
> didn't at some point in the past have the 407 response code and so you 
> can't really expect the server to generate it.
> 
> > I consider either of those procedures to be a gaping security hole - since
> > user:password information is being sent as cleartext (ie. base64) to
> > servers that are completely unrelated to other servers which the user
> > visited earlier which needed authentication.
> 
> Um are they?  If I understood you correctly the two authentication 
> demands were coming from the proxy server - not the remote target 
> server.  The proxy isn't going to pass this on to the remote server 
> (hopefully).  And you know its the proxy 'cos it says so in the realm 
> (plus your browser knows that its talking to a proxy in the first place).

*HOW* do I know it's the proxy asking for authentication?  Because of the
string of letters p r o x y in the realm name?  Read the spec - this is an
opaque string which must only be tested for equality with other strings
(and presented to the user, of course)

> But having said that without a 407 response, what else are you 
> going to do?  There are plenty of 1.0 proxies out there (lots of them 
> CERN ones).  If you don't send the authentication line you're going to 
> have alot of p*ssed off users who have to enter the same authentication 
> strings over and over again.  Bummer.

Well, I've told the user that it's just his hard luck, because I'm not
going to support the behaviour required.

-- 
Stewart Brodie, Electronics & Computer Science, Southampton University.
http://www.ecs.soton.ac.uk/~snb94r/      http://delenn.ecs.soton.ac.uk/
Received on Wednesday, 10 July 1996 17:12:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:19 GMT