[3059] in WWW Security List Archive
RE: Client->Proxy Authentification
daemon@ATHENA.MIT.EDU (Dave Dulfer-XMAC88)
Tue Sep 24 21:31:02 1996
Date: Tue, 24 Sep 1996 16:35:04 -0500
From: "Dave Dulfer-XMAC88" <Dave_Dulfer-XMAC88@email.mot.com>
To: "'myanez@ait.uvigo.es%INTERNET'" <myanez%ait.uvigo.es@INTERNET>,
"'dwm@shell.portal.com%INTERNET'" <dwm%shell.portal.com@INTERNET>
Cc: "'www-security@ns2.rutgers.edu%INTERNET'" <www-security#064#ns2.rutgers.edu@INTERNET.email.mot.com*RFC-822*>
Errors-To: owner-www-security@ns2.rutgers.edu
This wont work because the browser wont send a cookie to a host (or
domain) that didn't assign it. The result would be having to
re-authenticate every time you switched servers. Besides, about as many
browsers that support cookies, also support proxy authentication.
Netscape 2.0 and IE 3.0 (perhaps more) support it. If you can, bring up
your proxy according to http/1.1 (with respect to proxy authentication)
and require your user base to use one of these two browsers (or any
others you may find that support it). Considering these two browsers
account for the vast majority in use, I don't think it's an unreasonable
requirement.
--
David Dulfer E-Mail: xmac88@email.mot.com
Corporate Network Architecture Voice : (847) 576-8143
Telecommunications & Information Security Fax : (847) 576-6388
Motorola
>----------
>From:
> dwm@shell.portal.com%INTERNET[SMTP:dwm#064#shell.portal.com%INTERNET@email.m
>ot.com]
>Sent: Tuesday, September 24, 1996 2:15 PM
>To: myanez@ait.uvigo.es%INTERNET
>Cc: www-security@ns2.rutgers.edu%INTERNET
>Subject: Re: Client->Proxy Authentification
>
>
>
>On Tue, 24 Sep 1996, Maria Jose Yanez Freire (Paco) wrote:
>
>> I'm implementing a web proxy in an UNIX system and I need to know the uid
>>
>> of the client process who is connected to my proxy. HTTP authenfication
>> mecanism is not a good solution because is designed to authentificate a
>>user
>> with a server, not a proxy.
>> Another solution is the port 113 daemon defined in RFC 931 (used by NCSA
>>
>> 1.5 server) but many computers doesn't run this daemon.
>>
>> Is there any other solution?
>
>HTTP/1.1 provides for proxy authentication ... depending on your time
>frame and the clients you need to support and when they will have HTTP/1.1
>conformant clients, that is a possiblity.
>
>If your application server is tightly bound to its user community so that
>cookie tricks won't raise their ire, you might be successful with a
>combination of HTTP basic authentication and cookies.
>
>Basically your proxy adds its own cookie to each response such that
>the browser will always return the cookie. Your proxy also deletes the
>cookie from each request so it doesn't cause problems at the origin
>server. The trick is in the forcing of the cookie association with
>all requests.
>
>NOTE: This is an untried suggestion so prototype and
>test it carefully with *EVERY* browser you expect to support (EVERY
>includes brand, platform, and version).
>
>The trick is to subvert HTTP authentication. As a proxy, look at each
>request. If it includes your cookie, then you have you ID. If the
>request includes your authenticate response, delete it. Delete your cookie
>and forward the request.
>
>If your cookie is not present, issue a WWW-authenticate challenge for
>your domain as if you were simply a proxy for the challenge from the
>origin. THIS IS IMPORTANT .... with your challenge include your cookie.
>The response to the challenge will provide your userid. The cookie value
>you provide must be a unique token which you can now associate in your
>proxy with the userid each time you see a request. Delete the
>authorization header and forward the request. If the origin server needs
>to authenticate, it can do so as your cookie will stick and you don't
>need your authentication data any longer.
>
>This suggestion is not likely to be appreciated for an application which
>is intended for access by a socially dispersed group of users. It is also
>a hack which could get fragile in the face of very minor differences in
>browser implementation or other proxy based applications between the
>browser and your application.
>
>Dave Morris
>
>
