Re: Browser display of 403 responses bodies on CONNECT

On 18/06/2015 2:49 p.m., Adrien de Croy wrote:
> 
> 
> ------ 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.

Squid does at least. The guys doing Squid TLS decrypt tell me Chrome
barfs quite nasty binary errors at the user *unless* the proxy forges
certs and injects into the TLS stream.

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

It goes a bit deeper than that.

Some of the Mozilla bugs are for things like IMAP server connectivity
being broken sporadically. On deeper investigation it turns out the PAC
file is giving a set of HTTP proxy, one of which rejects (403) on
CONNECT to non-443 ports.

The user sees email update checks responding with a simple and clear "no
new mail" (so innocent and trustworthy) for a few hours despite new
email arriving constantly. Then something changes the PAC interpretation
and the other proxy gets through - wham!! a huge pile of emails to
download, instant network congestion and potential IMAP server overload
on SME systems.


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

Have a read through <https://bugzilla.mozilla.org/show_bug.cgi?id=479880>.

Amos

Received on Thursday, 18 June 2015 04:12:17 UTC