Re: Browser display of 403 responses bodies on CONNECT

>> 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.

Password in cleartext, maybe, or maybe not. But the point sticks: an
explicitly-configured proxy is a trusted component in a service chain,
either by deliberate choice of the user or of their IT department.

>> 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.

Yes, please! Want to be fancier? use an iframe-like structure, where
the outer frame is rendered by the browser and the inner frame is the
5XX body.
Specification-wise, a SHOULD-level statement could encourage this
while still keeping us out of the UX topic.

> 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.

>From my experience any medium-to-large enterprise would be very
tempted to go this route in order to reduce the number of support
calls and complexity of managing them.

> 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!

Yes.
A bit of pragmatism would do wonders :)

-- 
    Francesco Chemolli

Received on Tuesday, 23 June 2015 09:22:15 UTC