Re: Proxy authentication -Reply

jwilde@westpub.com wrote:
> 
> >According to this user, Netscape also suffers from this problem, but
> >MS-IE doesn't.

> Microsoft Internet Explorer has the ability to store passwords into
> memory.  The user is probably using this so he doesn't get prompted.  I
> think it needs to be IE 2.x and above.

I store authentication details for the current session (or permanently if
the user so desires, along with strong warnings about the security
implications of this)

> >First question: Is the proxy wrong to send a 401 response when it is
> >the
> >proxy that requires the authentication?  (I think it is) 
> 
>[description cut]
> Hence,  
>          it's not working because your proxy is set up tottally wrong.  The

I am the browser author (not of Netscape or MS-IE), and not the
adminstrator.  It is not `my' proxy.

> Server response is correct in returning the 401 because it is just
> forwarding your get requests and is acting as a server because of your
> mishap in the protection scheme with the proxy.  This is not true for the
> regular httpd server btw.

The proxy is *NOT* forwarding the request anywhere.  It is rejecting the
request with a response indicating that the *origin server* requires
authentication - this is clearly not the case, since it is the *proxy*
which wants the authentication.

The *only* style of HTTP authentication that can be used be proxies is
with "407 Proxy Authentication" response.  I can't find this in the draft
for HTTP/1.0 whih I have to hand, but that's old.  It's certainly in 1.1.

Non-HTTP ways of authenticating are also possible.  As you pointed out,
IP-based or domain name based access control is supported.

> >Second question: Now I can't see any way that MS-IE can possibly
> >know
> >to send the authentication every time.  Is it resending purely based on
> >the realm in the WWW-Authenticate directive?  If so, isn't this quite a
> >large security problem, especially since the basic authentication
> >scheme only uses BASE64 encoding?  
> 
> I have answered this above.  After recieveing a 401 from the server, IE
> sends out the default password which is stored by the user.  And realm

Are you saying that if I set up a custom server with an area protected by
Basic authentication, and MS-IE users visit it I automatically get to see
their passwords?!?

> is not the only directive when authenticating to http.  It is based on
> something called canononical root which would be everything till the last
> / in a string.  hence
> [examples cut]
> based on the server response.  if
> http://www.westpub.com:80/authenticate/to/me/ 
> was accessed and responded to authenticate to a realm the browser
> has already authenticated to, then the browser has the smarts to try the
> previously tried uid/passwd  or uid:passwd  which is in Base64
> encoding.

Wonderful.  So all I need to do is set up a few realms on my pages that
correspond to those used by other organisations, and I'll get to log their
passwords.

I wonder if you actually realise what I am talking about?

            User<------>Proxy<------>origin server

         request ------>
      401 reply  <------

ie. there is no conversation between the origin server and the proxy at
all.   For example, user issues request for:

http://www.ecs.soton.ac.uk/

User sends the following to the Proxy (a machine in Germany): 

GET http://www.ecs.soton.ac.uk/ HTTP/1.0

Proxy responds:

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"

This is absolutely wrong, IMHO.  There is no access protection on my
department's home page.  The proxy is lying.  My browser now prompts me
for a user/password to satisfy the host "www.ecs.soton.ac.uk" in realm
"ProxyWorldWide" (this is wrong! But the browser can do nothing else).

Browser resends request to proxy:

GET http://www.ecs.soton.ac.uk/ HTTP/1.0
Authorization: Basic BASE64("12345678:ABCDEFGH")

(where the user:password has been base64 encoded)

NOW the proxy talks to www.ecs.soton.ac.uk and returns the page.  Now
consider the user decides to not use the proxy any more.  User issues
request (having deleted any cached version) again (for the URL
http://www.ecs.soton.ac.uk/) but this time direct to
www.ecs.soton.ac.uk on port 80:

GET / HTTP/1.0

Does it send the authentication at this point?  You are implying that it
should, because the canonical URLs match.

Using the proxy again, going back to the previous stage about 15 lines
up where Authorization:  Basic was sent, the same authentication
information will be sent for any URLs underneath the
http://www.ecs.soton.ac.uk/ heirarchy.  I think this is correct.  (Do
you agree?).  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?  I can't believe that you are.  My user is claiming that with
MS-IE, this challenge is either being pre-empted by including the
Authorization header in the original request, or it is resending the
request with the Authorization header automatically with no user
intervention as soon as it sees that the request has failed - he
doesn't have to intervene in any way in order to make this request
succeed

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.

Further, what happens if the user *does* try to access a page which really
does require user authentication?  Is it supposed to start sending
multiple Authorization headers?

-- 
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 11:53:44 UTC