1140529 - allowing insecure content on a HTTPS site and redisableing it leads to unexpected results

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Tim [:pollti]]

Attachment: bug_mixedcontentF5-WindowsEnglish.gif

Allowing insecure content on a HTTPS site and redisableing it leads to problems:
1. When I refresh the site by pressing F5, insecure content is still enabled.
2. The insecure content icon in the adressbar isn't visible anymore.

STR:
#Go to a HTTPS website with visible insecure (HTTP) content. (e.g. https://people.mozilla.org/~mverdi/mockups/insecure.html)
#Allow insecure content.
#Disable insecure content.

Actual result:
*The icon in the adressbar disappears.
*Insecure content is still enabled.

Expected result:
*The icon should stay visible.
*Insecure content should be disabled.

To reset the insecure content status, reenter the URL and hit enter.

The following versions of Firefox are tested and affected:
*Firefox 36 on Linux
*Firefox 37 on Windows 8
*Firefox 38 on Windows 7
*Firefox 39 on Windows 8

Comment 1

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Related to bug 1045809 comment 35 / bug 1058086?

Comment 2

[Tanvi Vyas[:tanvi]]

When I try to reproduce this behavior on a page with mixed script, the script is blocked when it should be and unblocked when it shouldn't be - https://people.mozilla.org/~tvyas/mixedcontent.html

Looking at this test case closer, the <iframe src is to http://vine.co/v/bgbVbP0TKdK/embed/simple.  When Mixed Content Blocker see's an HTTP iframe on an HTTPS frame, it will block it.  Then we disable protection and load the frame.  The frame actually does a HTTP/1.1 301 Moved Permanently to the https version of the page (https://vine.co/v/bgbVbP0TKdK/embed/simple).  Since the page went through an insecure redirect, it still shows the mixed content yellow warning

But then when we enable protection, it looks like the original <iframe src=http> doesn't go through the MixedContentBlocker.  Instead we use <iframe src=https>.  The cached version.  Necko cache hits should still always go through MixedContentBlocker - or at least that's what I thought.  This needs to be checked in a debugger to see what is going on.

Revisiting the page in another tab, the <iframe> is blocked once again.  So perhaps this has to do with an odd interaction between our re-enable code and our caching code.

Needinfo'ing myself to dig deeper, but if anyone has time to look at this in the meantime, please do!

Thanks for the report!

Comment 3

[Tanvi Vyas[:tanvi]]

It looks like this testcase is gone but I created another one: https://people.mozilla.org/~tvyas/mixedcontentredir3.html

I also tried this with js and re-enabling protection works as expected: https://people.mozilla.org/~tvyas/mixedcontentredir2.html

So the issue seems specific to cached frames.

Comment 4

[Tanvi Vyas[:tanvi]]

This is a necko cache issue.  Necko cache is missing a call to content policies.

* Go to https://people.mozilla.org/~tvyas/mixedcontentredir3.html
* Gecko tries to load an iframe to http://people.mozilla.org/~tvyas/http_301_https.html
* Content Policy is called on the load and the frame is blocked by Mixed Content Blocker.

* Disable protection.  Page reloads with LOAD_RELOAD_ALLOW_MIXED_CONTENT flag.
* Gecko tries to load an iframe to http://people.mozilla.org/~tvyas/http_301_https.html
* Content Policy is called on the load and the frame is ALLOWED by Mixed Content Blocker because protection was disabled.
* Server responds with a 301 to https://people.mozilla.org/~tvyas/index.html
* Gecko tries to load an iframe to https://people.mozilla.org/~tvyas/index.html
* Content Policy is called on the load and the frame is allowed since its a secure https load.

* User re-enables protection. Page reloads without flags.
* Necko cache kicks in?  Not sure what happens here...
...
* Content Policy is called on the final load uri https://people.mozilla.org/~tvyas/index.html.  The load is allowed since it is secure.

Why didn't we get a content policy call to the first hop in the redirect (http://people.mozilla.org/~tvyas/http_301_https.html) after we enabled protection?

Patrick or Steve, do you know why only the last hop in a 301'd iframe go through content policy API?

Comment 5

[Tanvi Vyas[:tanvi]]

Thanks Tim for this live example!  http://youtube.com 301s to https://youtube.com.  Re-enabling protection doesn't block the load.

https://blog.mozilla.org/sumo/

Needinfo'ing mcmanus to see if he knows what's going on with the necko cache and 301 frames.

Comment 6

[Patrick McManus [:mcmanus]]

I can speculate, but honza (ni'd) is the expert on all cache interactions

Comment 7

[Honza Bambas (:mayhemer)]

This is a docshell "problem".  It remembers the shEntry for the subframe and just bypasses the redirect and CSP check entirely [1].  On reload you should use the nsIWebNavigation's LOAD_FLAGS_REPLACE_HISTORY flag.

[1] http://hg.mozilla.org/mozilla-central/annotate/767ea640b2f1/docshell/base/nsDocShell.cpp#l1433

Comment 8

[Boris Zbarsky [:bzbarsky]]

So...  On reload docshell will reload the URIs that are currently in subframes.

So for example say you load a page from https://A that has an <iframe src="http://B"> and the iframe has an <a href="https://C"> in it.  The user clicks that link, then reloads the toplevel page.  The docshell will do a load directly from https://C, since that's the thing currently loaded in the subframe.  This is more or less what comment 7 is saying.

For purposes of insecure content notification, it sounds like we actually want to do some sort of session history entry tainting or something if we want to display that insecure content icon here...

Comment 9

[Tanvi Vyas[:tanvi]]

(In reply to Not doing reviews right now from comment #8)
> So...  On reload docshell will reload the URIs that are currently in
> subframes.
> 
> So for example say you load a page from https://A that has an <iframe
> src="http://B"> and the iframe has an <a href="https://C"> in it.  The user
> clicks that link, then reloads the toplevel page.  The docshell will do a
> load directly from https://C, since that's the thing currently loaded in the
> subframe.  This is more or less what comment 7 is saying.
> 

Oh, that is very interesting!  On one hand, it means no insecure request is going to be made on reload.  We are just going to load the https top level page and the https page currently in the frame.

However, the https frame came from an http redirect.  Which means it could have been intercepted and changed to something malicious.  Arguably, the user has already hit the page once, so what's the big deal if they visit the page again?  But previously they saw a degraded security UI and now they see a lock.


> For purposes of insecure content notification, it sounds like we actually
> want to do some sort of session history entry tainting or something if we
> want to display that insecure content icon here...
Not sure how much we care about fixing this.  How many user's are disabling and then re-enabling protection anyway?  Not many.  We might even make the override UI less discoverable in the future.  If the solution is not as easy as setting a reload flag or adding a call to nsIContentPolicy, we may want to mark this won't fix.  I'd like Christoph and Dan's opinions here.