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

Hey Chris,

Thanks. A couple of thoughts below.


> On 27 Feb 2017, at 12:08 pm, Chris Bentzel <chris@bentzel.net> wrote:
> 
> 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.

Agreed.

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

I think only in response to a CONNECT to a explicitly configured proxy over HTTPS (with some discussion about what that means WRT autoproxy.conf with and without WPAD) would be a good start. 

What I'm hearing from the discussion is that while treating it like a unique origin (with significant control over UX, e.g., HTML) would be Nice To Have, at this point *any* ability to indicate the real nature of the problem would help avoid deploying more MitM, which I think is in everyone's interest.

The sweet spot sounds like it needs to balance the network administrator's desire to convey the reason (e.g., explanatory text) and their identity (e.g,. a name, perhaps an icon) with the browser vendors' need to minimise the new surface area exposed, as well as resources to implement. 

I wrote that draft with that in mind -- happy to change the details. 

Cheers,


--
Mark Nottingham   https://www.mnot.net/

Received on Monday, 27 February 2017 01:51:34 UTC