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 2:27:58 p.m.
Subject: Re: Browser display of 403 responses bodies on CONNECT

>On 17 June 2015 at 17:54, Adrien de Croy <adrien@qbik.com> wrote:
>>>  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.
>>
>>
>>  just to clarify then.
>>
>>  It's preferable to MITM the TLS to send a block page back, than to 
>>send a
>>  block page back on a 403 response to the CONNECT?
>
>That's a bit of a leap, isn't it?

I've seen code which does this, I can't remember sorry if it was in 
squid or hapoxy or nginx, maybe Willy or Amos can comment there.

>
>What I'm suggesting is that if you type https://blah and you don't get
>something that is authenticated as being from blah, then you expose
>yourself to problems.
I don't think you can claim that an http error response to the proxy 
tunnel setup could be considered as an authenticated response from a 
site.  If a browser gives that impression, the browser should be fixed.

The problem with displaying anything other than what the proxy responds 
with is that important diagnostic information from the proxy (e.g. the 
rule which blocked the request and why) is lost.

I could imagine a scenario where the client shows the response from the 
proxy in some way that makes it obvious it's not the site that was 
requested.  And could for example disable script, and hyperlinks if 
there really were safety concerns.

But protecting people from this hypothetical risk has real world 
consequences which is affecting people.  I'm not convinced that using a 
403 to provide someone with a fake site for phishing is a credible 
threat, it's certainly not the easiest way for a system admin to gain 
access to that data.

We are talking here about the proxy operator being the threat, since 
this is only for CONNECT which is only sent to a proxy that has been 
configured by the client.

>
>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.
Omitting it causes real problems.

>
>Rather than slinging mud, perhaps you could engage with browser
>vendors in the usual venues:
>https://bugzilla.mozilla.org/
>https://code.google.com/p/chromium/issues/list
>https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer
>https://bugs.opera.com/wizard/
>https://bugreport.apple.com/
>etc...


Until today I considered this a temporary bug, I didn't realize it was 
intentional.

On this note, there are many other responses to a CONNECT request which 
could be problematic, such as a 302, or 404.  CONNECT doesn't seem to be 
particularly well fleshed out in the documents.

Thanks

Adrien

>

Received on Thursday, 18 June 2015 02:52:24 UTC