Re: Browser display of 403 responses bodies on CONNECT

On Tue, Jun 23, 2015 at 05:10:11PM +1000, Mark Nottingham wrote:
> This was touched upon in WPD:
> 
> > When user agents encounter 5xx responses to a CONNECT request from a WPD proxy, they MUST present the response to the end user, but MUST NOT present or process it as a response to the eventual request to be made through the tunnel (i.e., it has an unidentified payload, as per {{RFC7231}} Section 3.1.4.1).
> > 
> > NOTE: Many user agents refuse to show an error response to a CONNECT to the user, in order to deal with the issues brought to light by {{bad-proxy}}. While effective in dealing with those attacks, doing so effectively disallows communication between the proxy and the end user; this requirement is designed to re-open that channel.
> 
> where {{bad-proxy}} is <http://research.microsoft.com/apps/pubs/default.aspx?id=79323>.
> 
> Fundamentally, I think this is a user experience problem, in that anything
> that can render HTML can fool some number of users thinking they're talking
> to the "real" Web site.

Not if they replace the URL in the bar with the proxy's URL. Also don't
forget that we're talking about trusted proxies, the ones the user is
sending his login and password in clear text to.

> For better or worse (I think better), we don't do UX here.

We don't do UX but we do care about sane error reporting. In my opinion,
even rendering the response as pure text (a la "view source") would be
fine. I've been a number of times in a situation where a proxy was
refusing to forward a connection to a site which was not whitelisted,
and which returned a nice page where you could click to request that the
site be whitelisted.

It seems it's not possible anymore with browsers not presenting the response.
The alternative as usual will be that proxies will have no other choice than
returning a 200 to pretend the connection to the destination was established,
and spoofing the certificate. And that's far from being perfect because then
it supposes the transported protocol is HTTPS while it isn't necessarily.

The use of proxies is clearly and cleanly defined in my opinion, and the
proxy has a number of options to cleanly refuse an action and to explain
its motives. If we squeeze these options, only the dirty ones remain, and
cause even more MITM deployments.

It's a bit "fun" to see that most of those nasty MITM deployments are caused
to preserve a user experience that is not respected by those who mostly focus
on it and who complain a lot about MITM!

Best regards,
Willy

Received on Tuesday, 23 June 2015 07:57:40 UTC