Re: Browser display of 403 responses bodies on CONNECT

On 18/06/2015 2:27 p.m., Martin Thomson wrote:
> 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?
> 
> 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.

The browser has gone nowhere near "blah". It is gone to its configured
proxy and been told "No. Pinky is awaiting a blue moon".

Browser displays:
- The website you connected to is not responding.
- TLS connection failure

or one of a number of completely unrelated false statements complaining
about service from "blah".

The *only* thing that works is MITM decryption and injecting a 403/511
response explaining the reality.


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

Such as 511? Browsers still refuse to implement support for that on
CONNECT. Anything that is non-200 status gets a browser custom error page.


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

Been there. Done that.

I've personally made reports to both IE and Chrome years ago, but had
them shunted away behind security lockdowns. So I've no idea how many
other complaints and discussions have been directed at those other
browsers. Their public bug systems are definitely not reflecting the
reality though. Even Firefox diverts into secrecy for a dependency bug
(<https://bugzilla.mozilla.org/show_bug.cgi?id=599295>). As mentioned in
some of the mozilla bugs reports (like
<https://bugzilla.mozilla.org/show_bug.cgi?id=491818#c44>), the major
browsers are all doing the same behaviour and reinforcing each other
like a cartel.


As I understand it the begining was this:
<https://bugzilla.mozilla.org/show_bug.cgi?id=479880#c1>.

That the browsers circa 2009 followed a 3xx redirect silently without
changing the address bar URL to reflect where the attacker was sending
the user, and running all operations within the security context of the
original URL.  Sound a lot like Alt-Svc to anyone else?

One would assume the correct fix is to update the address bar and
disable security context appropriately. But
<https://bugzilla.mozilla.org/show_bug.cgi?id=479880#c2>.

The problem with that is it results in
<https://bugzilla.mozilla.org/show_bug.cgi?id=479880#c75> and
<https://bugzilla.mozilla.org/show_bug.cgi?id=479880#c80>. Mozilla
bugzilla is now riddled with 2009, 2010, 2012, 2013, 2014, and 2015 bug
reports either directly or indirectly resulting from proxy CONNECT
respones being hidden from the users. Unexpected auth, certificate
handling, or TCP issues all show up as the generic custom browser
message. The response each time is demonstrated in
<https://bugzilla.mozilla.org/show_bug.cgi?id=491818#c56>, but I'm
currently counting 12 open CONNECT + 403/407/302/301 bugs from the past
year that have not yet been silenced with WONTFIX.


Decrypting the TLS and injecting responses "works" at unseen cost of
re-opening the original CVE issue.
 ... and sends one more sysadmin down that slippery slope of TLS MITM
towards simply decrypting everything and proxying the https://. Cache
HIT ratios get quite high in HTTPS due to lack of secure Cache-Control
headers :-(

Amos

Received on Thursday, 18 June 2015 03:57:12 UTC