Re: Proxy authentication -Reply -Reply

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.

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

>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?!?

yes i am saying that.. Whatever is stored within the password (assuming
they have it checked to always use this passwd) when the client
recieves a 401 from the server, the client will try that uid/passwd first by
default.  

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 don't think you understand here.  The string has to be matched also..
Let's say you were on host http://www.pconline.com
and you authenticated to REALM = realm1 at 
http://www.pconline.com/authenticate/
now if you goto http://www.pconline.com/another/directory/ with realm =
realm1 also, then the browser will pass the passwd.  Now, let's say
www.pconline.com has ip address of 204.1.1.1  now if i goto
http://204.1.1.1/authenticate/  (same host so same realm and i already
authenticated to it)  the client will not send up the uid/passwd because of
the 204.1.1.1 is different, the server will pass back a 401 not authorized
and then authenticate the normal way.. The only way you could actually
steal a uid/passwd is through MSIE or through fooling a dns to think that
your whom you are not.  (hope we are on the same wave length)

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

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

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


yep.. shouldn't get 401 because you shouldn't be using
Usernames/Password for proxy authentication with a cern proxy(unless
you authenticate by the following).  It is not supported.. Like i stated
earlier you have to do it by domain or ip.

>User sends the following to the Proxy (a machine in Germany): 
>GET http://www.ecs.soton.ac.uk/ HTTP/1.0
hopefully there is a space between / and 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"
Like i keep saying, this proxy is set up the wrong way.. check out:
http://www.w3.org/pub/WWW/Daemon/User/Proxies/Proxies.html#protect

>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
I know that.. the proxy want's to be authenticated to, but it's set up
wrong.  The response doesn't get forwarded to your server.

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.

no www.ecs.soton.ac.uk and www.ecs.soton.ac.uk:80  are definitely
different are they not?  one has :80 one doesn't.



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?).  

yes you are correct.. by the way i've network traced all of this so i'm
positive.

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"

probably didn't make it past the proxy even.


(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 don't quite understand this part.  I just know that MSIE has remember
password built in.  I don't know why he made it by the authentication.
you said it wasn't authenticated. and it does not go with the header
unless it is in the cannonical root.  Which means you would have had to
have received an 401 previous to that.

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.

Security hole for whom?  It would not be a security hole for anyone but
the user whom is giving out there passwd, and the places he
authenticates too.



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? 

nope it will not.. the server won't understand it.  They will fail and then
have to manually enter it.


Jeff Wilde
jeff.wilde@westpub.com

Received on Wednesday, 10 July 1996 14:24:25 UTC