493699 - Firefox display "Proxy Server Refused Connection" instead of custom error page when connect to HTTPS site which blocked by proxy server

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[bugz]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.9.0.10) Gecko/2009042718 CentOS/3.0.10-1.el5.centos Firefox/3.0.10
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.9.0.10) Gecko/2009042718 CentOS/3.0.10-1.el5.centos Firefox/3.0.10

Firefox display "Proxy Server Refused Connection" page, instead of Squid custom error page, when connect to HTTPS site which blocked by proxy server.
For example we try to connect to https://www.redhat.com via Squid proxy server which denied with 403 error this connect and send custom error page with description of problem. In Konqueror, for example, all work fine. In older Firefox version it's worked too.

Reproducible: Always

Steps to Reproduce:
1. Configure Firefox to use proxy server (SSL Proxy).
2. Try to connect to HTTPS site, which will be blocked by proxy server
Actual Results:  
Firefox will display "Page Load Error" with description "Proxy Server Refused Connection. Firefox is configured to use a proxy server that is refusing connections."
If we connect to HTTPS site which not blocked by proxy server - all works fine.

Expected Results:  
Display proxy server error page with deny info.

I had disabled all plugins before this test

Comment 1

[Jason Duell]

This is an intentional change.  We no longer render reply content from proxies over HTTPS for security reasons.

Most of the boilerplate error pages that you now see are similar to the default Squid error pages.   Were you replying with something significantly different than squid's default page content?

Comment 2

[Jason Duell]

Note that one workaround for this is to issue a redirect (via a 302 or other 3xx HTTP status code) rather than a 403.  Point the redirect to a URL for your custom error page.  This will work in Firefox 3.0.12 (and 3.5RC1) and later.

Our apologies for the inconvenience.

Comment 3

[bugz]

This is very strange. First question is what is that security reason?
And, I'm think, answer "Proxy Server Refused Connection" is not right answer. It misleads user!
In our reply we tell user, that connection to this site now denied, but he can call to admins and fix it. We allow HTTPS connection only to listed sites for security reason in our organisation.
And you think that render proxy answer is more dangerous than redirect user to another site? I'm think you are wrong.

Comment 4

[oobermick]

I work for a web filtering company and we are seeing this problem when we block https sites (we've not had a compliant from a customer yet but when we do I'll redirect them here ;)).

Can you explain why it makes sense to respect a 302 and not a 403?  Surely the information given back from the proxy is always useful and should be used to explain what is happening to the user?

Comment 5

[Jason Duell]

Reopening this bug.  We should find a way to safely display proxy replies when SSL connect requests are rejected.  I think we were optimistic when we thought just returning a boilerplate page would be an adequate UI compromise here.

> Can you explain why it makes sense to respect a 302 and not a 403?

It doesn't make sense.  This was not a policy decision, it was an architectural one; we had to fix a security issue, and while it was easy within the fix to support allowing proxy redirects, allowing other reply codes will take more work.  I'm reopening this bug so we can get started on supporting rendering other proxy replies.

Unfortunately, there's almost no chance that a fix for this is going to make it into the next firefox 3.0.x or initial 3.5 releases, which are essentially code frozen.  So the current behavior--which I'll fully admit is not desirable--is going to be around for some time.  If you want your users to see custom error pages when you deny them an SSL connect, you will have to issue a redirect to a URL for an error page, as per comment #2.  (Yes, this is stupid, and extra work for you.  Our apologies.)

Comment 6

[oobermick]

Thanks for taking the time to reply, I suppose we will have to work around this problem in the mean time.

Thanks again.

Comment 7

[Jason Duell]

So, Jonas suggested to me that one way to fix this might be to use the redirect infrastructure.  I've poked around at this, and the idea I've got is to 

1) keep the existing channel, but change its target URI from the original requested URI (paypal.com, etc.) to the URI for the proxy server. 

2) call OnChannelRedirect() with the existing channel as the "new" channel (i.e. keep the channel open, but have DocShell, etc., consider this a redirect).  This ought to allow the reply from the proxy to be read from the original channel, and get treated by DocShell as coming from the proxy's URI.

Does this seem like a feasible plan? I tried a quick and dirty test implementation, and it didn't work, but I suspect that's because (at a minimum) we would somehow need to re-run the channel's OnStartRequest().

Comment 8

[Boris Zbarsky [:bzbarsky]]

That doesn't sound good to me.  In particular, it sounds like it would pass (incorrectly) the cross-site redirect checks in XHR and the like.

If you're going to call OnChannelRedirect, you need to create a new channel, basically.

That said, how did chrome and IE8 fix this issue?  I'd rather get some more data here before we start flailing about and declaring our fix (not showing the proxy's response page, which we can't tell apart from an attempted attack on the user) bad.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Note also that if we didn't have all sorts of moronic code assuming that the page URI can be used for security checks you could also just give the channel a null principal and be done with it.  But we do.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Oh, and to answer comment 3, the issue is described in bug 479880 (which I've cced you on).  I believe the researchers who discovered the issue plan to publish in the near future once all the relevant browsers have fixed it; in the meantime, please keep the details confidential.

Comment 11

[Boris Zbarsky [:bzbarsky]]

And just to clarify comment 8, I'd rather not show the proxy response at all than try to neuter it while showing it... that way there isn't this issue of the response maybe working maybe not depending on phase of moon and what we decide is dangerous, nor is there an issue with us missing something in the sandboxing.

Comment 12

[Adam Barth]

> That said, how did chrome and IE8 fix this issue?

Chrome blocks all these responses from proxies (including the redirects).  I think they show a slightly more informative message about being unable to establish a secure connection.  I haven't tested IE8.

Comment 13

[Adam Barth]

By the way, the paper is now public.  We can probably remove the security sensitive flag on the other bug.

Comment 14

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Why not create a new channel instead of modifying the existing one? That's what we do in all other redirect cases so that's what i'd think is the safest thing to do.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Adam, can you please contact Daniel Veditz about doing that?

Jonas, that's what we'd have to do if we go the redirect route, yes.  But the new channel would have to hand back the data from the old channel... or something.  It'd require some serious httpchannel surgery, which doesn't seem worth it to me.

Comment 16

[Jason Duell]

I'll check IE 8, Safari, and Opera's behavior on this today.

Comment 17

[Jason Duell]

So I've looked, and as of today only Opera is doing the "right thing" and rendering HTML content from 403 proxy replies to HTTPS requests.   IE 8, Safari, and Chrome all display boilerplate error pages.  (See the paper mentioned in bug 479880 to see why everyone is treating HTTPS proxy replies with a 10-foot pole now.)

Given that this would be a lot of work to make 403 replies render safely, and most everybody else is punting too, I think we have a new web standard :(

(This reminds me of the old joke "How many Microsoft developers does it take to change a light bulb?"  "None, Bill Gates just declared darkness the new standard".  Except that we're part of the problem too this time...)

Finally, there's a chance we may scrap handling redirects, too.  Keep an eye on bug 491818 if you're interested.

My apologies to the web proxy developers out there.

Comment 18

[Wan-Teh Chang]

Jason: before the "Pretty-Bad-Proxy" paper was published, Safari
was already displaying boilerplate error pages for HTTP CONNECT
non-200 (or perhaps non-2xx) responses.

You can at least map 403 to a new error code that means "the
proxy blocked connection to the website" in
nsHttpChannel::ProcessFailedSSLConnect.

We all want to display the custom error pages from proxies,
but the error pages must have the security context of the
proxy rather than the destination HTTPS server.  It'll be a
lot of work to implement this correctly and to review it.

Comment 19

[Jason Duell]

> You can at least map 403 to a new error code...

The current message is this:

"The proxy server is refusing connections:  Firefox is configured to use a proxy server that is refusing connections."

It doesn't seem that bad to me, but we could add a new error page that says something like "Your proxy server refused to load this page."   I'm not sure if it's worth it, and I'll leave it to our UI folks to decide (open a new bug if you want a different error msg).

Comment 20

[Alain Knaff]

The current message looks as if it's a reuse of the message that pops up if the proxy is not running.

Are error messages really so expensive that we have to reuse them?

If we must map all proxy answers to a single boilerplate, can't we at least make it truthful (such as "Proxy returned an error, but unfortunately we cannot display it due to security reasons. See <link> for explanation"). This way, users won't lose time doublechecking that the proxy port is correct, and network admins won't lose time restarting a proxy server which was running fine all along.

Comment 22

[Jason Duell]

I agree with comment 18 and comment 20.  Opened bug 637619 to deal with it.