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: 1. 2. 3.
wfm with a current cvs trunk build, normal proxy auth from squid (proxy_auth) is used, squid version used is 2.4.STABLE7
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.
I've created an example test case: ---- #!/bin/sh echo 'Status: 407 Proxy Authentication Required' echo 'Proxy-Authenticate: Basic realm="Proxy Password"' echo exit 0 ---- The above CGI can be tested at http://www.snert.com/proxy-auth.cgi It generates the following output from my server: ---- GET /proxy-auth.cgi HTTP/1.0 Host: www.snert.com 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.
Mozilla 1.8a4 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040911 Still exhibits the problem.
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.
err, i mean Bug 205947
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.
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.
Some definitions from RFC 2616, section 1.3: proxy 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. gateway 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.