Closed Bug 613489 Opened 14 years ago Closed 8 years ago

Proxy Server Refused Connection when using https

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: mozilla, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.10) Gecko/20100920 Fedora/3.6.10-1.fc13 Firefox/3.6.10
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.10) Gecko/20100920 Fedora/3.6.10-1.fc13 Firefox/3.6.10

On Windows, Firefox displays "Proxy Server Refused Connection" when any error (not necessarily connection refused) occurs while trying to connect to a https site.


Reproducible: Always

Steps to Reproduce:
1. Connect to https://www.lll.lu using a proxy needing password authentication
2. Deliberately enter wrong password

(this is just an easy way to show how to reproduce the problem. It seems that this message comes for _everything_ as long as the URL scheme is https.)
Actual Results:  
It says "Proxy Server Refused Connection".

Expected Results:  
It should say "the user's password could not be verified or is not correct", or whatever else the proxy returns in such circumstances.

There are a number of other wonky error messages in Firefox, which are displayed in situations to which they don't apply.

It's almost to the point that you can no longer trust Firefox' messages and have to doublecheck using another program (other browser, or telnet, ...).

Misleading error messages are doubly harmful:
- they lose time immediately, by sending people on a wild-goose chase
- they teach users that error messages are not to be trusted, wasting precious help desk time even in situations where they are relevant and to the point

Firefox should give a good example here, and not contribute to the mess.
What is the response from the server ?
Is there a redirect in the content ?

This is disabled for security reasons (bug 479880)
Well, I couldn't unfortunately get the response in the original case where I observed this (as that was windows...), however I managed to reproduce the problem on Firefox 3.6.12 on Linux, with the following proxy response.

HTTP/1.0 403 Forbidden
Server: squid/2.7.STABLE7
Date: Mon, 22 Nov 2010 20:07:45 GMT
Content-Type: text/html
Content-Length: 1193
X-Squid-Error: ERR_ACCESS_DENIED 0
X-Cache: MISS from hitchhiker.hitchhiker.org.lu.hitchhiker.org.lu
X-Cache-Lookup: NONE from hitchhiker.hitchhiker.org.lu.hitchhiker.org.lu:3128
Via: 1.0 hitchhiker.hitchhiker.org.lu.hitchhiker.org.lu:3128 (squid/2.7.STABLE7)
Connection: close

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>ERROR: The requested URL could not be retrieved</title> <style type="text/css"><!--  %l  body :lang(fa) { direction: rtl; font-size: 100%; font-family: Tahoma, Roya, sans-serif; float: right; } :lang(he) { direction: rtl; float: right; }  --></style> </head><body> <div id="titles"> <h1>ERROR</h1> <h2>The requested URL could not be retrieved</h2> </div> <hr>  <div id="content"> <p>The following error was encountered while trying to retrieve the URL: <a href="www.ltml.lu:443">www.ltml.lu:443</a></p>  <blockquote id="error"> <p><b>Access Denied.</b></p> </blockquote>  <p>Access control configuration prevents your request from being allowed at this time.  Please contact your service provider if you feel this is incorrect.</p>  <p>Your cache administrator is <a href="mailto:webmaster%W">webmaster</a>.</p> <br> </div>  <hr> <div id="footer"> <p>Generated Mon, 22 Nov 2010 20:07:45 GMT by hitchhiker.hitchhiker.org.lu.hitchhiker.org.lu (squid/2.7.STABLE7)</p> <!-- ERR_ACCESS_DENIED --> </div> </body></html>


I read bug 479880, and now I understand a bit better what is going on in this case. Thanks for the pointer.

However, while I understand why this kind of "fix" is needed in situation where there is an emergency (such as a security hole), I don't quite get why this situation still exists 21 months later. Many different solutions could be considered, many of which have been pointed out by contributors to bug 479880. Here a couple of examples, listed here in order of decreasing desirability and complexity:

1. Set up a special document domain for the proxy. Proxy-returned javascripts would run in that domain, without risking being confused with code coming from the server.

2. Disable javascript processing in proxy responses, but display the rest.

3. Toss everything but the status line ("HTTP/1.0 403 Forbidden" in my example)

4. Toss even the status line, but for the love of God, don't reuse an error message from an entirely unrelated condition. Instead, create a new one: "The proxy signaled an error while trying to forward your request to the https server. For security reasons (<link to explanation>), the error message could not be displayed".


As for redirects injected by the proxy, these could be disabled, or replaced by a widget that the user has to click manually in order to follow the redirect.


The problem of reusing error messages for unrelated conditions seems to be endemic in firefox, see also bug 554055 and bug 408794

When doing stuff such as this, think about the poor users and helpdesk personnel which must make sense of these misleading error messages.
Component: General → Networking
Product: Firefox → Core
QA Contact: general → networking
This is basically bug 493699#c17 but I leave this open for bug 493699#c19
The proxy responds with a 403 which basically means it rejects connections so that makes Firefox correct here. If the proxy deems the authentication to be wrong/missing it should respond with a 407.
you can resolve invalid
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.