Chrome won't render the content of a 502 /302 proxy reply on an SSL
Reported by anci...@gmail.com, Mar 23 2012
Chrome Version : <Copy from: '17.0.963.83 m'> OS Version: Windows 7, Win 2003 URLs (if applicable) : see issue description Other browsers tested: IE - default behavior fails as with chrome. However Microsoft has provided a workaround by applying a certain reg change FEATURE_SHOW_FAILED_CONNECT_CONTENT_KB942615 Reference: 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 FireFox : Current behavior fails however they will provide a workaround more or less same as microsoft. reference: https://bugzilla.mozilla.org/show_bug.cgi?id=493699 Safari 5: Not tested Chrome won't render the content of a 502 /302 proxy reply on an SSL What steps will reproduce the problem? 1. request e.g. https://www.google.com 2. use a proxy that would block such request (filter). 3. Chrome will display the following default error message instead of the one sent by proxy - use sniffer to verify that actual content was delivered and revived by chrome. This webpage is not available The webpage at https://www.facebook.com/ might be temporarily down or it may have moved permanently to a new web address. Error 111 (net::ERR_TUNNEL_CONNECTION_FAILED): Unknown error. is there currently a workarround to display/render such content ? Is there a plan for near future to provide such feature ? Thanks!
Mar 23 2012,
There are some non-trivial security implications of showing such a response - such that the 302/502 script will run in the same origin as the target domain. This provides attackers a vector for things such as cookie hijacking. Given that few proxies support the newly-added-in-Chrome HTTPS protocol, this is a very tempting attack vector (eg: an attacker on a network can interpose themselves as a SOCKS/HTTP proxy without detection). I've cc'd rch and flagged it, just in case I'm misremembering the details, but I believe this is a WontFix for security reasons. At best, we might want to improve the error text, and if so, this bug description should be updated, but I don't think we have any plans to compromise the security as you've requested. wtc: IIRC, this is covered in the "Pretty Bad Proxy" paper. Do you have any thoughts?
Mar 25 2012,
You should consider rendering a “Safe HTML” removing scripts from HTML or Plain test message only stripping all HTML /Script tags – may result in “non esthetic” page however it is safe. The issue is where internal, trusted proxies, sending a customized error message – such as a page blocking message, and such customized error is not rendered ending up with an arbitrary error message at the client end – no way that end point can understand why original request wasn’t retrieved.
Mar 10 2013,
Apr 28 2015,
Jun 14 2016,
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Jun 20 2016,
I'm going to move to WontFix. The request is understandable (proxies can provide custom error messages), but the general area around tunneled-connections-through-proxies has historically been fraught with security bugs (such as 407's which get handled by the same origin).
Sign in to add a comment