User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 The settings "security.warn_viewing_mixed" (default true) and "security.warn_viewing_mixed.show_once" (default true) control the message boxes that appear when you visit a mixed secure / nonsecure web site. If you visit such a mixed page then a warning message pops up. But you have check a box in that message to get such alerts for other mixed pages in the future, if you just click OK then there are no future warnings. Even if you slect to be warned then you only get a warning when you visit such a page that only has an OK button. After you click the button then the page loads, including the nonsecure content. Internet Explorer handles this better. In IE it is not configurable if you get this warning or not, there is no "don't show me again" checkbox or setting. Also the message box in IE says "this page contains both secure and nonsecure items, do you want to display the nonsecure items?" Replying "No" will result in only the secure content being loaded. In general all the security.warn_* behaviour should be reversed. You should get these boxes until you click "don't show me again", instead of the current set where you have click "continue showing me these warnings". Reproducible: Always Steps to Reproduce:

I believe IE7 will just not load the insecure items.

*** Bug 344889 has been marked as a duplicate of this bug. ***

Full implementation blocked by bug 135007, but even in the cases we catch (such as frames) we simply show the "mixed" lock icon (and optionally an alert, but not a confirmation box that allows the user to cancel). Dropping the insecure loads entirely and getting rid of "mixed" mode would be the best thing. That might even be easier to implement (could we use nsIContentPolicy? Something right in Necko?).

Not blocking on this for Firefox 2 due to low priority and fact that bug 135007 was also minused.

(In reply to comment #3) > Dropping the insecure loads entirely and getting rid of "mixed" mode would be > the best thing. That might even be easier to implement (could we use > nsIContentPolicy? Something right in Necko?). Please see bug 62178 comment 69 why nsIContentPolicy can not be used. I propose we try to get the resources to get bug 62178 fixed.

(In reply to comment #5) > > Please see bug 62178 comment 69 why nsIContentPolicy can not be used. That is, we can not show a prompt (asking for permission) when using nsIContentPolicy.

> That is, we can not show a prompt (asking for permission) when using > nsIContentPolicy. Who wants a prompt? I'm suggesting dropping insecure parts of a secure document entirely, no questions asked. Maybe a developer pref to re-enable mixed-mode for people who are developing a multi-host web site where not all the pieces have certs yet (but will by "release").

(In reply to comment #4) > Not blocking on this for Firefox 2 due to low priority and fact that bug 135007 > was also minused. And this bug was not fixed in Fx2. Both IE6 and IE7 will warn unconditionally (you can't select to not receive the warning again) and offer you a choice of loading or not loading the insecure content. Also, IE6 and IE7 will not show any padlock icons if you load the insecure content. (They will only show a padlock icon if only the secure content is loaded.) In Fx2, by contrast, a locked padlock with a thin red stripe will be displayed in the address and status bars, although the address bar will not turn yellow. This striped locked padlock can easily be mistakes for a real locked padlock on a secure site.

(In reply to comment #7) > > That is, we can not show a prompt (asking for permission) when using > > nsIContentPolicy. > > Who wants a prompt? I'm suggesting dropping insecure parts of a secure document > entirely, no questions asked. Maybe a developer pref to re-enable mixed-mode > for people who are developing a multi-host web site where not all the pieces > have certs yet (but will by "release"). Even if we do not show a prompt, and use a "supress insecure content by default", we will need a fix for bug 62178 which is supposed to implement the necessary backend change to suppress a load before it happens.

Isn’t bug 59637 a duplicate of this bug (or the other way round)?

This seems like a decision for the firefox team. Moving the bug over there. I remember talking about this a long time ago though, so I bet this bug is a dup of something older out there.

Johnath: where does this fit in with the thoughts we'd been having about what to do with mixed content vs. encrypted vs. non encrypted ...?

(In reply to comment #12) > Johnath: where does this fit in with the thoughts we'd been having about what > to do with mixed content vs. encrypted vs. non encrypted ...? IMO, the UI for mixed content is almost secondary to the ability to just block the insecure content in the first place, as a couple commenters have pointed out. This means finding someone who can tackle bug 62178, which unfortunately isn't me. Kai has an old patch there, but I think he needs help bringing it into the current codebase. I'm going to try to get jst or bz interested in it this week, but would be happy to harass others as well, if there are suggestions.

I think we want to block insecure content, but we can probably allow images and the like safely. Not sure if we need UI.

fwiw, this is the bug to do the blocking, so if you want that to go in for FF3 then this bug should be marked a blocker. The reason the fix has to live in FF code is that we need to ask the user before doing the blocking. Renominating just in case.

In reply to comment 14: There was a famous case of a stock broker who was delivering on-the-fly generated images of graphs showing the stock and portfolio values of the user's account over the previous 30 days. The page was an https page, but the graphs were being delivered over http. The insecurity was made conspicuous because the insecure images were not being shown, and they were the whole focus of the page. This case showed that we cannot assume that image content is not security sensitive. We should suppress all insecure content. We should not even fetch it. We know it will be insecure before we fetch it. We definitely should not send the insecure request and then decide, after the request and response have traversed the network, that there is a security problem. (That is the essence of bug 62178.)

the backend does not support this behaviour, we need bug 62178 fixed to have this in the front end. restoring minused blocking flag, nominated the backend bug...

So is that to say that we don't consider the feature as must-have? I couldn't find this in the PRD so that does seem right, but I thought that we had talked about it. If we do consider it must-have I think this should be marked as blocking, it's too hard to find all features being blocked in a blocking bug so it's likely going to be marked blocking- if this one is.

As of today, my understanding is: Yes, we really should improve our mixed-content-story. I propose we make it a very high priority for Firefox 4. Yes, we really need the backend support from bug 62178 and 135007/135011. Yes, I agree that this bug and bug 59637 are very closely related. Bug 59637 just asks for any mechanism to either show or not show the insecure content on a secure page. This bug explicitly proposes the mechanism that should be used: Using an option in the security transition warnings. Now, from what I've learned in the discussions around bug 62178, bring up a prompt in the middle of nsIContentPolicy is really hard. But luckily, it seems, the latest thinking is: Let's not use a prompts. Let's use a policy. In other words, our default policy might be: - Block insecure on a secure page - Make the user aware (potentially using a yellow information bar) So, the override to unblock the insecure content would not be done by a prompt, but by entering a kind of override rule (like we do it for cookies, software installation or cert exceptions). Yes, other browsers show the prompt and offer an immediate decision/override for the scope of the current page. (Even Netscape Navigator 4.x did it this way.) But because we can't easily use a prompt, and because we tend to prefer the policy/override approach, I propose: - This particular bug is WONTFIX Instead, we should get 62178 etc. fixed, implement the load policy configuration, then implement the warning and override UI (for mixed content). We might want to use bug 59637 to track that work.

We really want this, but we need the core bugs fixed to allow this...

So.. this might be too extreme. But it would be awesome if we could completely block mixed content. Most of the time you really don't want mixed content anyway. That we could definitely do without minimal changes in core code. One tricky issue would be what to do with content that is securely loaded, but loaded from a site with a different cert. Not sure if that is bad or not?

For any of these changes, I'd like to see test builds before we land them on the trunk. I suspect that we will need to refine things a bit before making these part of the nightly builds. Not loading mixed content and the other ideas are good, but may have unintended consequences, like by changing layout, not loading style sheets, included Javascript, just to name a few. If things *do* break, and if it's the right thing from a security point of view, we'll want to evangelize the changes very early in the process.

(In reply to comment #21) > One tricky issue would be what to do with content that is securely loaded, but > loaded from a site with a different cert. Not sure if that is bad or not? I'd say different certs are fine, as long as each cert passes our validity tests. Many sites load content from multiple servers. The main page www.paypal.com page loads content from a paypalobjects.com domain (https).

Yeah, I agree that different certs sound fine. Here is what I propose: When a page contains mixed content refuse to load it, but show an info bar (or whatever that yellow thingy is called) stating that some loads were blocked and allow the user to override this. We should make it clear that overriding is a dangerous operation even if the user trusts the current site. If the user still chooses to override, reload the whole page while loading the mixed content. When mixed content loads are allowed, always break the lock icon. Not sure what to do with the larry indicator. In the messaging around this new behavior, make it clear to website admins that we are planning on removing this option so they really need to fix their sites. Possible implementation strategy: Create a content-policy that checks a flag on the loadgroup, and if that flag isn't set simply refuse loading mixed content. This code would also need to listen to redirects. When a load is blocked also send a notification to the front-end code about this happening. If the user chooses to override, set a flag on the loadgroup stating this and reload the page. We should probably allow this to be remembered on a per-uri basis, and ideally only per session. It's a little tricky what to do for POST loads since we really don't want the user to resubmit the POST. Don't really have any good ideas there, unless we can somehow grab the old POST result from cache.

I'm worried that refusing to load mixed content will discourage sites from using https. I don't like it when behavior intended to improve security on https sites ends up discouraging sites from using https (cf bug 424872). For example, refusing to load mixed content would break the "display images below" command in https Gmail. Preventing webmail providers from using https would be worse than the current problems, IMO. Can we make an exception for images, or give Gmail a way to say "Please allow *this image* to load over http without prompting the user"?

Me and Dan talked about images. I think for now we should leave images as is, as I understand it they don't even trigger the mixed-content warning now. This would result in far fewer sites "breaking" over the new strategy, thus making it less likely that we'll have to back off of it. For things like <script> I think we want discourage sites to use https for the main content but http for <script>. Doing that just gives the user and the site operator a false sense of security since the site is no safer than if the whole thing had been loaded over http.

I get a broken-lock icon when I click "display images below" in Gmail.

Please note there have been a lot of discussions on this topic already, and ideas and proposals and problem descriptions can be found here: https://wiki.mozilla.org/Security:PresentationOfStates

We need the backend ability to block before load. Someone needs to focus on bug 62178 and get it done.

Loading the mixed content and showing a 'warning' is an incredibly dumb design decision, IMO. In car terms, it's the same as replacing the rear proximity warning beep with a dashboard indicator that only flashes AFTER you've reversed your vehicle into an unseen obstruction. Thank you. Amazingly helpful (facepalm). This is a case where IE does it entirely right and Firefox obstinately continues to do it entirely wrong. The only sane option is a 'Do you wish to proceed' type button (YES/NO) BEFORE the browser loads the insecure content, so the user can safely back out if proceeding could load compromising content. Allow a user to disable the warning, sure, but at least have the functionality there in the browser so users can choose whether to browse safely or not when encountering mixed content on secure domains.

Looks fixed in Firefox 23.0.1 per http://www.mozilla.org/en-US/firefox/23.0.1/releasenotes/ and https://blog.mozilla.org/security/2013/05/16/mixed-content-blocking-in-firefox-aurora/

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)