Re: The future of forward proxy servers in an http/2 over TLS world

[Chris Bentzel <[e-mail]>]

Hi - interesting discussion. I work on Chrome but not on UX.

---

We could probably look at improving the UI around
ERR_TUNNEL_CONNECTION_FAILED listed further up the thread. Thanks for
bringing that up.

---

I think it would be interesting to have a consistent error code(s) for
responding to a CONNECT in a way that specifies the proxy is blocking it.
This could help non-browser-clients understand what's going on, and even if
browser clients don't want to display strings/UX provided by the proxy it
would be able to provide more details. Sorry if this was already discussed
(I saw 451 mentioned for example). This would ideally let users know that
their access is being blocked, but would not give richer information (like
who to contact) if response code with custom browser UX is used.

---

In terms of showing a response body, there are two concerns:

a) There have historically been a number of attacks around 407 and
responses to CONNECT [1][2][3]. While these are ultimately implementation
issues rather than fundamental problems, this worries me that it will
likely open up another attack.

b) To limit, the body would need to be treated as from a totally unique
origin or even just plain text. You could imagine plain text showing up
similar to a beforeunload handler or alert for example. However, these have
been increasingly been abused for scams. It wouldn't be a stretch of
imagination to think of a proxy which blocks access to a site with text of
"Access to facebook blocked because we detected you have a virus. Call
1-800-555-1212 to talk to our technical support."

Given the high prevalence of WPAD in clients it'd be a bit scary to even
show text in that case. Arguably if a proxy is explicitly specified and
uses https it may be reasonable to then show the text in the response body
even if it doesn't work in the common case.


[1]:
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/pbp-final-with-update.pdf
[2]: http://falseconnect.com/
[3]: https://bugs.chromium.org/p/chromium/issues/detail?id=431504


On Fri, Feb 17, 2017 at 8:04 AM Francesco Chemolli <[e-mail]>
wrote:

>
> On 17 Feb 2017, at 12:14, [e-mail] wrote:
>
> So there *is* blocking at the gateway level, there *will* *be* blocking at
> the gateway level, the question is not whether this blocking should exist
> or not, but if the user experience can be made less miserable than it is
> today [...]
>
>
> ..Following up with with 10 minutes of open stage enthusiastic standing
> ovation.
>
> I support this description of the state of things, and the conclusion.
> Let's remember that there's not only browsers: HTTP is taking over the
> role of transport for most remaining holdouts of other mechanisms for
> sever-to-server inter-organisation message passing. In this use-case the
> user interface is obviously much less of an issue (if at all), but the
> use-case for to a centralised HTTP L7 forward control point is very much
> there.
>
> I've had several conversations with UA contributors over this, and from
> what I recall everyone agrees that the presentation side of things is the
> most critical aspect; I hope this thread will renew interest in finding a
> solution, ideally shared so to give end-users the least surprise.
>
> Francesco Chemolli (kinkie)
> Squid
>