[1903] in WWW Security List Archive
Re: Proxy Authentication
daemon@ATHENA.MIT.EDU (David Dulfer)
Wed Apr 24 15:20:28 1996
From: "David Dulfer" <xmac88@il06pop.corp.mot.com>
Date: Wed, 24 Apr 1996 11:24:51 -0700
In-Reply-To: @email.corp.mot.com:bretg#064#ctt.bellcore.com@INTERNET
"Re: Proxy Authentication" (Apr 24, 8:22am)
To: bretg@ctt.bellcore.com, etdrc@public.bta.net.cn
Cc: www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
There is a difference in the way CERN and Netscape have implemented proxy
authentication. CERN grew up originally as a server and still uses regular
server authentication (eg. sends a status code 403 to the client for each new
host/realm). The client believes it is authenticating with a server rather than
a proxy. The side effect of this with Navigator is that it takes this literally
and forces a re-authentication. I don't believe this is the case with other
browsers (someone with a CERN proxy test this and correct me if I'm wrong).
The Netscape proxy server implemented the 407 status code which is used
specifically for "Proxy Authentication". It is handled differently than a 403 by
Navigator and the other browsers that implement it. Browsers that don't
implement it wont recognize the 407 status code and, therefore, wont know that
they need to authenticate. Microsoft IE has this problem.
On Apr 24, 8:22am, @email.corp.mot.com:bretg#064#ctt.bellcore.com@INT wrote:
[snip]
> This tells me one of two things:
>
> 1) the CERN proxy just does HTTP redirects
> instead of "true" proxying. I find this hard
> to believe, as a major value of a proxy is
> in the caching that can be done if it sees the data.
This is false and would make the CERN proxy unusable in a firewall situation.
[snip]
>-- End of excerpt from @email.corp.mot.com:bretg#064#ctt.bellcore.com@INT
Hope this helps.
--
David Dulfer E-Mail: xmac88@email.mot.com
Corporate Network Architecture Voice : (847) 576-8143
Telecommunications & Information Security Fax : (847) 576-6388
Motorola
