Re: Browser display of 403 responses bodies on CONNECT

------ Original Message ------
From: "Martin Thomson" <martin.thomson@gmail.com>
To: "Adrien de Croy" <adrien@qbik.com>
Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
Sent: 18/06/2015 11:57:42 a.m.
Subject: Re: Browser display of 403 responses bodies on CONNECT

>On 17 June 2015 at 13:47, Adrien de Croy <adrien@qbik.com> wrote:
>>  we're seeing nowadays many browsers don't display the content of a 
>>403
>>  denial response to a CONNECT request, instead displaying some generic
>>  home-baked browser warning about being unable to make a connection.
>
>I believe that this is because our users have requested a secure site
>and anything other than authenticated content provided by that site
>would present an unparalleled opportunity for MitM phishing attacks.
how would this be any more or less of an opportunity than a block page 
for http?

Fundamentally the client is using a proxy, and made an HTTP request to 
the proxy for a tunnel which it denied.  This is before accessing the 
site, this is the tunnel setup stage which is HTTP not HTTPS.
To not display the block page from the proxy is just problematic and 
leads to support calls.

At the moment we have to respond to customers who query this with saying 
it's a browser bug not displaying the block page.

>
>>  Is there any language in the RFC that encourages or discourages this
>>  behaviour, or should there be?
>
>I don't believe that there is any requirements on how content is
>rendered, no.  Nor should there be.
I wasn't talking about how to render, I was talking about whether to 
display a message body or not.

If we're not deprecating message bodies on CONNECT unsuccessful 
responses, they should surely be displayed.

>
>RFC 2616 had some language around presentation to users, and asking
>for permission and so forth, but I believe that was one thing that was
>cleaned up in the latest round.

Received on Thursday, 18 June 2015 00:52:12 UTC