Open Bug 637619 Opened 14 years ago Updated 7 months ago

Display better error messages when HTTPS proxy servers return non-200 error codes

Categories

(Core :: Networking: Proxy, defect, P5)

Product:
Core
Component:
Networking: Proxy
Type:
defect

Tracking

()

People

(Reporter: jduell.mcbugs, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-would-take])

Followup from bug 493699 (and the basic bug 479880). We're not going to display whatever content a proxy server sent along with a non-200 HTTP response, but we could switch from the current, somewhat ad-hoc set of boilerplate replies chosen from the existing set of Firefox error messages (i.e. "Proxy server refusing connections", etc) to a new set that displays something as accurate as possible, including new boilerplate error messages if needed. Alas, the correct message to display is not always so clear from the status code: there's a lot of drift between the HTTP spec and what proxies actually do in practice, so many codes are overloaded. See the comments and logic in nsHttpChannel::ProcessFailedSSLConnect: http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpChannel.cpp#810 If anyone with some domain expertise here can suggest a better (and researched in the real world) set of error messages for the various error codes, I'd be up for changing the logic, including adding new error pages. I don't have time to do the research myself, and I suspect proxy authors/admins may be in a better position to know anyway.
Problem still exists in 3.6.15, in a slightly different shape. I had accidentally left an (external) proxy configured for a site which is in our local network (due to bug 642396). I got a message that was styled like a local browser error message saying that site was unreachable... with no hint at all that this was a proxy message! Useless debugging of our firewall config until I noticed that request went through proxy... If you cannot use the proxy's message "as is" at least make it clear that this is what is happening ("Proxy returned an error, details cannot be displayed for security reasons") rather than make it look like a local problem. Moreover, wouldn't it solve the security issue by just stripping all HTML markup from the proxy's response, but leaving the actual text intact? Or only stripping "dangerous" HTML tags (so that the proxy's response doesn't turn into a jumbly mess if it contains multiple paragraphs or lists)
> Moreover, wouldn't it solve the security issue by just stripping > all HTML markup from the proxy's response We considered that at one point, but concluded that 1) full markup stripping would be pretty ugly, and 2) partial markup could be tricky to get right from a security perspective. That's what I recall being told by my betters at the time...
Maybe we could define a header whose content is displayed, if present?
Markup stripping would be ugly? So, what's the purpose of an error message: is it more important that it is beautiful, or is it more important that it is useful and helps in actually guiding the problem? Well, different people may indeed have different priorities, so why not make this an about:config option?
bz: how much do you still stand by bug 493699 comment 11?
As stated there, fully. If we just stripped all markup, I'd be more ok with that, but even that's a hard problem... Or we could display the response, whatever it is, as text/plain; the problem there is that it would be well-nigh unreadable. I suppose we could also try to use some sort of sanitizing parser; I hear Henri is working on that. > is it more important that it is beautiful, or is it more important that it is > useful and helps in actually guiding the problem? "Ugly" means things like "just dump the HTML as plaintext" here. It's not clear how "useful" that would be to someone trying to then read the gunk. Markup stripping often leads to similar outcomes, by the way: the result is completely unreadable.
(In reply to comment #6) > I suppose we could also try to use some sort of sanitizing parser; I hear Henri > is working on that. After I learned that a sanitizing parser was trouble and after I realized that the use cases I was addressing didn't require a sanitizing *parser* anyway, I wrote a DOM fragment sanitizer instead, and the plan is not to have a sanitizing parser. That is, with the current plan, the isn't going to be a way to ask a parser that is consuming a network stream to output a sanitized DOM. My first reaction is that making proxy errors better isn't compelling enough a reason to change that plan, but then I don't use proxies, so I'm biased.
(in reply to comment #6) > "Ugly" means things like "just dump the HTML as plaintext" here. It's not clear how "useful" that would be to someone trying to then read the gunk. Why do you think that this would be useless in all cases? > Markup stripping often leads to similar outcomes, by the way: the result is completely unreadable. If this only happens "often" rather than "always", it means that there are still many cases where it would stay readable. Would it be useful to keep the info at least for these cases? Right now, we're denying users access to the result, even in cases where it would stay readable.
> Why do you think that this would be useless in all cases? It wouldn't be useless in _all_ cases. Clearly, some people can read HTML. It would be pretty useless for most people, though. And when it's useless it creates a terrible user experience, which I think outweighs the benefits.... Jason, what do you think of handling these sort of things by synthesizing a page with a null principal and some sort of innocuous URI? It would take a bit of work, but would be the "right" solution to this problem.
http://openfwtk.cvs.sourceforge.net/viewvc/openfwtk/fwtk/squid-gw/connect.c?revision=1.20&view=markup see lines 151-187 I AM a proxy developer. Anything would be better than current "solution". Proxy developers may change default pages to plaintext. Proxy administrators may do that as well. But dropping all information on the floor is definitely *not* acceptable.
One solution is to accept text/plain responses from the proxy and display them in the context of a network error page (i.e., that explained to the use that the text came from the proxy and not the web site they were trying to reach).
Probably bug 157531 also wants a synthesized error page.
Is there a workaround for this issue with current Firefox version? Will you consider a workaround such as Microsoft did with IE - described here: http://blogs.technet.com/b/nettracer/archive/2011/09/22/internet-explorer-doesn-t-display-isa-or-tmg-error-message-502- when-connecting-to-https-servers.aspx JJ.
You mean you don't mind it's off by default?
Yes, make it off by default, but make sure that the replacement error message contains the following 2 items: 1. Explanation what is happening (real proxy error message cannot be displayed due to security reasons) 2. Instructions how to switch setting on in order to see real message from proxy.
In summary, there are 2 plans: 1. Synthesize (comment #9) 2. Off-by-default (comment #15)
(In reply to Alain Knaff from comment #15) > Yes, make it off by default, but make sure that the replacement error > message contains the following 2 items: > > 1. Explanation what is happening (real proxy error message cannot be > displayed due to security reasons) > 2. Instructions how to switch setting on in order to see real message from > proxy. not sure about (2) where i can find "Instructions how to switch setting on" ?
(In reply to O. Atsushi (Torisugari) from comment #16) > In summary, there are 2 plans: > > 1. Synthesize (comment #9) > 2. Off-by-default (comment #15) Thanks for reply! So it is planned for future releases or currently supported? any documentation available ?
(In reply to john from comment #17) > (In reply to Alain Knaff from comment #15) > > Yes, make it off by default, but make sure that the replacement error > > message contains the following 2 items: > > > > 1. Explanation what is happening (real proxy error message cannot be > > displayed due to security reasons) > > 2. Instructions how to switch setting on in order to see real message from > > proxy. > > not sure about (2) where i can find "Instructions how to switch setting on" ? Sorry, I'm not sure I'm understanding your question here. My message was a message to whoever would fix this, to remind them to not only include a text explaining what happened, but also a hint about how to address it (for example, by toggling a setting in about:config). The wording of that second part could be something like "in order to see the actual error message sent by the proxy, go to about:config and set network.proxy.show_message to true. Be aware that this may introduce a security risk if you don't trust your proxy or the network to your proxy"
(In reply to Alain Knaff from comment #19) > (In reply to john from comment #17) > > (In reply to Alain Knaff from comment #15) > > > Yes, make it off by default, but make sure that the replacement error > > > message contains the following 2 items: > > > > > > 1. Explanation what is happening (real proxy error message cannot be > > > displayed due to security reasons) > > > 2. Instructions how to switch setting on in order to see real message from > > > proxy. > > > > not sure about (2) where i can find "Instructions how to switch setting on" ? > > Sorry, I'm not sure I'm understanding your question here. > > My message was a message to whoever would fix this, to remind them to not > only include a text explaining what happened, but also a hint about how to > address it (for example, by toggling a setting in about:config). > > The wording of that second part could be something like "in order to see the > actual error message sent by the proxy, go to about:config and set > network.proxy.show_message to true. Be aware that this may introduce a > security risk if you don't trust your proxy or the network to your proxy" I misread your previous reply. I would like same solution/workaround as you asked for. BTW - does chrome support such feature as IE (as Ive added to description above) Thanks !
Bug 479880 is a relatively dangerous bug. We should carefully consider whether or not we may use off-by-default in a safe way. Maybe we should wait for new technologies e.g. <iframe sandbox> (bug 341604) or they're still dangerous...
The iframe sandbox bug has been completed if that would help with this bug. This is a big issue because it looks like the Internet connection is down ("I can get there on my phone"), increasing support calls. I couldn't find a related bug, but the 3xx response workaround doesn't work any longer. With a 302 response you get: "Title:Page Load Error; Body: Failed to Connect/The connection was refused when attempting to contact ..." And a 403 you get: "Title: Page Load Error; Body: Proxy Server Refused Connection/The connection was refused when attempting to contact the proxy server you have configured. Please check your proxy settings and try again."
Any progress on this? The bug is still present an regularly I lose some time tracking down phantom "network timeouts" which are really this bug. Please, make it at least so that it sth like "proxy detected an error, sorry we can't give you any details", rather than sending people on wild goose chases with fake "network timeout error"s. (Ok, at least the fact that this "timeout" pops up so quickly is a tip-off, but still...)
As a service provider with hundred of schools using our proxy service and with more and more websites prompting to use HTTPS, the stagnation on this issue is not maintainable anymore. Our support desk is getting a non negligible number of requests for us to provide a differentiation between 'administratively denied' and 'connection fault'. One solution would be for browsers to implement a new 5xx error code with a clear 'connection denied' semantic. The browser could then include a new error page, possibly including a simple line of text reported by the browser (optionally) explaining why the connection was refused. If acceptable, my organisation is willing to work on a draft-RFC document defining this code to get out of this impasse. However such work has no value if no browser's vendor is willing to implement it, therefore I am seeking Mozilla's position on this approach.
Patrick, thoughts on comment 24?
Flags: needinfo?(mcmanus)
I'd be happy to see standards work here
Flags: needinfo?(mcmanus)
Whiteboard: [necko-would-take]
Then I will start to work on a draft RFC document - happy to collaborate with anyone with enough time to help. https://github.com/thomas-mangin/draft
Patrick, that's good to hear. Thomas - I don't think we need a new status code here; the semantics of the existing ones should be sufficient, and new status codes are more work both for standardisation and implementation. My thinking is that we can do this with a new media type; something that conveys a constrained set of information from the proxy to the browser, to be presented to the user more safely. I've taken a quick stab here: https://mnot.github.io/I-D/proxy-explanation/ (Thomas: happy to work with you, this was just the easiest way to sketch it out) As it is, I suspect that this is only going to be used in CONNECT responses (i.e., it won't work for transparent proxies), because of the risk of an origin posing as a proxy. Would love to hear from browser security folks about how concerned (or not) they are about that, though.
Mark, Thank you for putting this together - I will collaborate with you on github. I am happy with your approach which goes further that I was willing to ask but is an overall better solution. I totally agree this should only be accepted by browsers if a proxy was explicitly configured. It could also be a configuration option on the browser (but this is beyond the RFC to define). The json message(s) may want to be returned in UTF-8. The draft may also want to allow replies using the new 481 code. There is also a small security consideration as the user may click the link and therefore any message relaid may require some some a 'warning' as a MIM attacker could pretend to be the proxy. I will make sure we have an implementation of the draft, hopefully within this week, on our open source proxy: https://github.com/exa-networks/exaproxy
s/481/451/ ... :-)
Thomas - good point about the security consideration. A browser *could* decide to only support the new media type when the proxy is configured to use HTTPS -- nice carrot/stick :)
I am sure one can have too many configuration options but only turning on the feature if an proxy is configured for the relevant protocol seems careful. I am not sure the field 'moreinfo' is wise though. It provides an URL to the client and as the browser can not be sure it is speaking to the expected proxy (MIM attack), this field could be used to trick the end-user to click on an malicious URL. Therefore in order to protect end users, I would suggest its removal (the text should be more than enough to explain the policy) and even perhaps encourage clients to be suspicious of any URL in the text and at least make sure they can not be clicked on.
I'm not sure; I think it depends on what the UX of the feature is. E.g., if a browser just puts the JSON into a HTML template and presents that, any Web site or MitM can fake that -- even today. OTOH if it's a privileged UX (one that can't be imitated by HTML+JS+CSS), users *might* become used to trusting it. I'd love to hear some implementer / security folk input. Barring that, leaving it open for experimentation is the usual path here, so that the security teams can find the right balance.
The draft https://mnot.github.io/I-D/proxy-explanation/ (-01) is now implemented by ExaProxy. You can run it by doing: > git clone git@github.com:thomas-mangin/exaproxy.git > cd exaproxy > env exaproxy.http.connections=100 exaproxy.tls.enable=false exaproxy.security.connect=80 exaproxy.redirector.enable=true exaproxy.redirector.program=etc/exaproxy/redirector/icap-deny-proxy-explanation exaproxy.redirector.protocol='icap://' ./sbin/exaproxy This proxy will refuse ANY connection to any site returning a 403 page with a application/proxy-explanation+json payload. You can test it running: > ./QA/test/connect-http-google-proxy-explanation
Regarding the security consideration about the URL provided. A solution could be to make it 'clickable' if the domain part of it is the same as the proxy setup on the browser. Some more elaborate code could look at the DNS reply and figure its domain.
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5
Arriving to the bug because 403 responses to CONNECT from the proxy server are displayed as generic "The proxy server is refusing connections". The proxy server has some acl entries in order to authorize access to some servers, this is no problem when the page is not over HTTPS, the proxy response is fully displayed, but in the case of HTTPS responses they aren't. I understand that showing the proxy response contents for a proxy CONNECT request is somewhat dangerous, the user may be tricked they are accessing the real page. With the increase of usage on encryption on the web, it has increased our support requests because users think the proxy is down, and not that the network policies prohibit access to those pages (think for example a hospital cashier/biller that only have access to banks and insurance providers web pages). I think a small change that could help, without the complexity of showing/sanitizing the proxy CONNECT response, it is to show a user friendly error message, after the "The proxy server is refusing connections", for example, if the proxy response is 403, say something like "The proxy server is refusing connections, access is forbidden", or something like that. I wish this detailed message is added, if accepted I could provide a patch, because the other option is to do TLS/SSL interception in order to show the proxy response. I want to avoid that, some proxy installations are for small businesses that don't need the burden of securing the proxy CA keys properly.

This is still a problem in the current Nightly builds (66.0a1, 2019-01-17). I was going to file a bug when I noticed a dozen bugs for the same problem. Please fix this because the current error message is just factually wrong.

See Also: → 1545421
Severity: normal → S3

Moving bug to Core/Networking: Proxy.

Component: Networking: HTTP → Networking: Proxy
You need to log in before you can comment on or make changes to this bug.