[10130] in www-talk@info.cern.ch
Re: Proxy authentication -Reply
daemon@ATHENA.MIT.EDU (S.N.Brodie@ecs.soton.ac.uk)
Wed Jul 10 17:18:01 1996
From: S.N.Brodie@ecs.soton.ac.uk
To: J.P.Knight@lut.ac.uk (Jon Knight)
Date: Wed, 10 Jul 1996 22:13:09 +0100 (BST)
Cc: S.N.Brodie@ecs.soton.ac.uk, jwilde@westpub.com, www-talk@w3.org
In-Reply-To: <Pine.SUN.3.91.960710210750.19314c-100000@weeble.lut.ac.uk> from "Jon Knight" at Jul 10, 96 09:26:13 pm
Resent-From: 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/
