Re: Browser display of 403 responses bodies on CONNECT

This was touched upon in WPD:

> When user agents encounter 5xx responses to a CONNECT request from a WPD proxy, they MUST present the response to the end user, but MUST NOT present or process it as a response to the eventual request to be made through the tunnel (i.e., it has an unidentified payload, as per {{RFC7231}} Section 3.1.4.1).
> 
> NOTE: Many user agents refuse to show an error response to a CONNECT to the user, in order to deal with the issues brought to light by {{bad-proxy}}. While effective in dealing with those attacks, doing so effectively disallows communication between the proxy and the end user; this requirement is designed to re-open that channel.

where {{bad-proxy}} is <http://research.microsoft.com/apps/pubs/default.aspx?id=79323>.

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. For better or worse (I think better), we don't do UX here.

Cheers,


> On 18 Jun 2015, at 7:00 pm, Willy Tarreau <w@1wt.eu> wrote:
> 
> On Thu, Jun 18, 2015 at 04:51:28AM +0000, Adrien de Croy wrote:
>> 
>> 
>> ------ Original Message ------
>> From: "Amos Jeffries" <squid3@treenet.co.nz>
>> 
>>> Have a read through 
>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=479880>.
>>> 
>>> Amos
>> 
>> that's really sad.
> 
> Indeed. IMHO the problem above is caused by the confusion between the proxy
> and the origin. A proxied response doesn't come from the origin until the
> 200 appears. The only origin without 200 is the proxy itself, and if it was
> handled this way there would be no problem with cookies.
> 
> Willy
> 
> 

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

Received on Tuesday, 23 June 2015 07:10:49 UTC