Re: Browser display of 403 responses bodies on CONNECT

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

Even though in many scenarios (e.g corporate LANs) this is an extremely 
unlikely scenario, I guess there are some cases where this might be 
possible.

It does seem a shame that all the millions of real corporate proxy users 
need to suffer because of paranoia over a vanishingly small possibility 
of an active network attacker.

But I believe the approach taken was expedient and heavy handed.  It 
should be possible for a browser vendor to distinguish this, and portray 
it in a way that allows the user to also distinguish it.  If we really 
are to take the stance that we don't do UX, we should not water down the 
spec to cater for lazy UX implementations either.

Adrien


------ Original Message ------
From: "Nicolas Mailhot" <nicolas.mailhot@laposte.net>
To: "Martin Thomson" <martin.thomson@gmail.com>
Cc: "Adrien de Croy" <adrien@qbik.com>; "HTTP Working Group" 
<ietf-http-wg@w3.org>
Sent: 24/06/2015 8:23:54 p.m.
Subject: Re: Browser display of 403 responses bodies on CONNECT

>
>Le Jeu 18 juin 2015 04:27, Martin Thomson a écrit :
>
>>  Now, if you wanted to fix this situation, I might suggest that a
>>  custom error page might be appropriate.  That page might say that the
>>  proxy denied the request to connect.  Showing content that the proxy
>>  provided still seems inadvisable.
>
>Excuse me but that's pretty braindamaged. Just because browser people 
>have
>repeated this for years does not mean it is true.
>
>The proxy is not an evil hijacker, the browser *chose* to use the proxy 
>so
>it can assume its choices.
>
>If browser authors are "afraid" of "evil" block pages (why are they
>connecting to this equipment in the first place?) they can add whatever
>chrome they wish around the block pages to show it's a block page 
>(exactly
>like they do for all other error messages)
>
>Also the pages browsers replace 403 with are intentionnaly misleading 
>and
>disparaging and designed to increase support calls. That's the browser
>choice but the http spec is not here to promote and condone such
>antisocial behaviour
>
>Regards,
>
>--
>Nicolas Mailhot
>
>

Received on Wednesday, 24 June 2015 10:05:34 UTC