Proxy Authentication no longer working




14 years ago
14 years ago


(Reporter: achowe, Assigned: darin.moz)


Windows XP

Firefox Tracking Flags

(Not tracked)





14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040909
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040909

Between Mozilla 1.8a3 20040901 and Mozilla 1.8a4 20040909, proxy authentication
is now broken, where it once worked. Receiving an HTTP response "407 Proxy
Authentication Required" with the corresponding header `Proxy-Authenticate:
Basic realm="Be Clever"' no longer evokes the username/password dialogue box as
it once did.

Reproducible: Always
Steps to Reproduce:

Comment 1

14 years ago
wfm with a current cvs trunk build, normal proxy auth from squid (proxy_auth) is
used, squid version used is 2.4.STABLE7

Comment 2

14 years ago
Well I have a test case on my workstation using a local web server and an
nph-CGI that I've developed that fails for Mozilla 1.8a4 and works for Opera
7.54. Last week it was working with the previously installed Mozilla 1.8a3.

The CGI sends only 3 lines:
HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="Proxy Password"


Mozilla used to respond to this with username/password dialogue. Now it does not. 

Comment 3

14 years ago
I've created an example test case:
echo 'Status: 407 Proxy Authentication Required'
echo 'Proxy-Authenticate: Basic realm="Proxy Password"'

exit 0

The above CGI can be tested at It generates
the following output from my server:
GET /proxy-auth.cgi HTTP/1.0

HTTP/1.1 407 Proxy Authentication Required
Date: Sun, 12 Sep 2004 15:15:15 GMT
Server: Apache/1.3.27 (Unix)
Proxy-Authenticate: Basic realm="Proxy Password"
Connection: close
Content-Type: application/x-httpd-cgi
Content-Language: en


Mozilla 1.8a4
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040909

Prompts to save the output instead of prompting for username and password. Opera 
Version	7.54 Build 3865 behaves as expected and IE 6 is broken, but I don't use
it real life.

I will download the latest nightly build to see if has been fixed since 20040909.


Comment 4

14 years ago
Mozilla 1.8a4
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040911

Still exhibits the problem.

Comment 5

14 years ago
Does this only occour with this testcase or also with a real proxy? If only with
the testcase, than this bug is probably invalid. This was done intentional then
by Bug 85484:
+        // only allow a proxy challenge if we have a proxy server configured.
+        // otherwise, we could inadvertantly expose the user's proxy
+        // credentials to an origin server.  We could attempt to proceed as
+        // if we had received a 401 from the server, but why risk flirting
+        // with trouble?  IE similarly rejects 407s when a proxy server is
+        // not configured, so there's no reason not to do the same.

Comment 6

14 years ago
err, i mean Bug 205947

Comment 7

14 years ago
Only with the test case since I have no other proxy (other than my current
development project) with which to test.

However, I would question the reasoning of only performing a challenge for an
explicitly configured proxy server. This does not allow for transparent proxy
servers that want the user to authenticate. An authenticating transparent proxy
would be useful in a company, school, internet cafe that wants to limit access
to the web without requiring workstations to be configured for a proxy, which a
power user could then circumvent.

The application that I'm developing and testing is intended to be a transparent
authenticating proxy server.
transparent proxies could just send a 403 auth required. proxy auths have
certain additional privileges that normal webpages should not be able to exploit.
(In reply to comment #8)
> transparent proxies could just send a 403 auth required

err. that should be 401, of course.

Comment 10

14 years ago
That is not suitable.  

A transparent proxy cannot use 401/WWW-Authenticate to authenticate the
connection. A RFC 2616 conforming transparent proxy must relay the
WWW-Authenticate header to the origin server. If a transparent proxy were to use
401/WWW-Authenticate, then the proxy would end up filtering Authorization
headers for itself, instead of passing it to the orgin server for authentication
at the far end. 

Proxy-Authenticate and WWW-Authenticate have very distinct purposes and you
cannot mix them. Nor can you exclude the use of Proxy-Authenticate by a
transparent proxy.

Mozilla must not ignore Proxy-Authenticate from a transparent proxy.

Comment 11

14 years ago
Some definitions from RFC 2616, section 1.3:

    An intermediary program which acts as both a server and a client for the 
  purpose of making requests on behalf of other clients. Requests are serviced 
  internally or by passing them on, with possible translation, to other servers. 
  A proxy MUST implement both the client and server requirements of this 
  specification. A "transparent proxy" is a proxy that does not modify the 
  request or response beyond what is required for proxy authentication and 
  identification. A "non-transparent proxy" is a proxy that modifies the request 
  or response in order to provide some added service to the user agent, such as 
  group annotation services, media type transformation, protocol reduction, or 
  anonymity filtering. Except where either transparent or non-transparent 
  behavior is explicitly stated, the HTTP proxy requirements apply to both types 
  of proxies. 

    A server which acts as an intermediary for some other server. Unlike a 
  proxy, a gateway receives requests as if it were the origin server for the 
  requested resource; the requesting client may not be aware that it is 
  communicating with a gateway.

From section 1.4:

  There are three common forms of intermediary: proxy, gateway, and tunnel. A 
  proxy is a forwarding agent, receiving requests for a URI in its absolute 
  form, rewriting all or part of the message, and forwarding the reformatted 
  request toward the server identified by the URI. A gateway is a receiving 
  agent, acting as a layer above some other server(s) and, if necessary, 
  translating the requests to the underlying server's protocol.

From this text it is apparent that you are talking about a gateway and not a
transparent proxy, because any proxy (transparent or non-transparent) must be
configured explicitly by the user-agent.  I believe you are misusing the
transparent proxy term.  (I think it is commonly misused.)

There are no provisions in RFC 2616 or 2617 for gateway authentication. 
Moreover, Internet Explorer 6 is likewise strict about rejecting 407 responses
when a proxy server is not explicitly configured.  Not doing so is a significant
security risk to the user because it would allow any server on the web to act
like a proxy server and potentially trick the user into revealing their proxy
logon credentials.  Mozilla ignores 305 responses for similar (and other) reasons.

It was a bug that Mozilla allowed origin servers to send 407, and it is likewise
a bug that Opera allows it.

Before disabling 407 for non-proxy servers, I did some google searching, and I
found a related thread on the squid mailing list about this issue.  Apparently,
the squid developers agree that it is not possible to issue 407s when squid is
used in "transparent" (i.e., gateway) mode.

Marking INVALID.
Last Resolved: 14 years ago
Resolution: --- → INVALID

Comment 12

14 years ago
QA Contact: core.networking.http → benc


14 years ago
You need to log in before you can comment on or make changes to this bug.