Re: Browser display of 403 responses bodies on CONNECT - a proposal

This issue keeps cropping up in support.

I understand what the browser vendors stated position is, although I 
believe with a little more imagination and effort there would be a way 
to display the proxy block page in a way that didn't confuse users.  But 
putting that argument aside, there is another safe (IMO) option for 
dealing with proxies blocking CONNECT requests.

Use (e.g. don't ignore) the response status code.

It's one thing to ignore the response message body on a 403 because it 
may have come from an active network attacker.

It's another thing to ignore the status code (the 403 itself).  That's a 
text-book example of throwing babies with bath water.

Instead of displaying a generic browser error page exhorting users to 
undertake all manner of wasteful misguided efforts (such as checking the 
site is up, checking their internet connection etc etc), how about 
instead displaying a specific error page for the case where a proxy has 
denied a tunnel connection to a site.

Just so users can know that they are being denied, and so if they have 
an issue with that they can take it up with management / sys admin 
instead of embarking on a wild goose chase about site connectivity.

Adrien

------ Original Message ------
From: "Amos Jeffries" <squid3@treenet.co.nz>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 25/06/2015 12:12:43 a.m.
Subject: Re: Browser display of 403 responses bodies on CONNECT

>On 24/06/2015 11:08 p.m., Roland Zink wrote:
>>  Btw. this is great if you want to run HTTP2 between browser and proxy 
>>as
>>  Chrome supports protocol negotiation with ALPN. Any proxies 
>>supporting
>>  this? It worked for me with nghttp2.
>
>SSL/TLS has been accepted by Squid since, oh ... 1997.
>
>ALPN is in the current stables, but only "negotiating" for HTTP/1.1.
>When we get HTTP/2 into mainstream it will be supported there too.
>
>>
>>  Roland
>>
>>
>>  On 24.06.2015 12:54, Roland Zink wrote:
>>>  On 24.06.2015 12:03, Adrien de Croy wrote:
>>>>
>>>>  I think the problem scenario is the active network attacker between
>>>>  the client and the proxy.
>>>>
>>>>  Since the client to proxy connection is not secured, the attacker 
>>>>can
>>>>  send anything back they like (including a 200 OK, but connect to
>>>>  something else or not).
>>>  This needs to be changed, although some browsers already support
>>>  secure connections to the proxy. Chrome can do secure connections to
>>>  the proxy when given HTTPS instruction (instead of PROXY) in a PAC
>>>  file. Anybody know if it will display error messages from the proxy 
>>>then?
>
>If I'm understanding it right theres no difference on those 
>connections.
>I've not a clear picture there though.
>
>Amos
>
>

Received on Monday, 7 September 2015 23:19:23 UTC