Please read my blog's comment policy here.
Update: IE9 includes improved handling of Mixed Content. Click to learn more...
As we developed Internet Explorer 8, we spent quite a bit of time pondering what to do about IE7’s infamous “Mixed Content” warning prompt:
As I noted on the IEBlog four years ago, the mixed content warning occurs when a web developer references an insecure (http) resource within a secure (https) page. Such references create vulnerabilities that put the privacy and integrity of an otherwise-secure page at risk, because the insecure content could be modified in transit. If added to the DOM, insecurely-delivered content can read or alter the rest of the page even if the bulk of the page was delivered over a secure connection. These types of vulnerabilities are becoming increasingly dangerous as more users browse using untrusted networks (e.g. at coffee shops), and as attackers improve upon DNS-poisoning techniques and weaponize exploits against unsecure traffic.
From a security standpoint, our best option would be to suppress the prompt altogether and simply make the secure choice on the user’s behalf, blocking all insecure content in secure pages. Unfortunately, as I mentioned in my MiX 2009 Security session, security is usually easy, but tradeoffs are often hard. If we were to simply automatically block the insecure content, we risk confusing the user; pages which rely on insecure images, stylesheets, or scripts could appear broken. In the worst case, the user might think the broken pages indicate a bug in IE8 and subsequently revert to an older version of the browser to get the prompt and unbroken pages.
In an attempt to resolve the compatibility / security tradeoff, we experimented with a number of concepts. For instance, we tried blocking insecure content in secure pages by default, with an information bar that allowed refresh of the page with mixed content permitted.
In our testing, we discovered a number of important scenarios where this approach introduced a much more severe problem-- data loss. For instance, when the user is composing a blog post or email message on a secure site, they might type or copy/paste a reference to an insecure resource within that message. When the information bar is subsequently used to unblock the mixed content, the blog post or email message would be lost because the web application was refreshed. If we didn’t refresh the page after permitting the mixed content, the page could break anyway, because the insecure resource would be run out of its normal order.
Ultimately, we concluded that removing the prompt wasn’t feasible. In IE8, we continue to rely on web developers to fix their pages to remove insecure content vulnerabilities; pages without such vulnerabilities won’t trigger the prompt.
Though we couldn’t get rid of it entirely, we did make some improvements to the prompt to correct several violations of our secure design principles. We identified three major problems with the older version:
1> The secure choice is not the default option.
2> The prompt does not clearly identify that the user is being asked to make a security decision.
3> The prompt does not offer the user enough information to make a safe choice. Specifically, it doesn’t indicate what the consequences of their choice might be.
To address these issues, we changed the default behavior of this prompt such that the secure option is the default; if the user simply clicks through, the page remains secure. We also updated the title, question, and explanatory information to help users understand the implications of the security decision they are being asked to make. The new prompt appears as follows:
If the user chooses “No,” then the insecure resources are displayed in the page and the lock icon is removed from the browser address bar.
If you encounter a mixed content warning, feel free to point the website administrator to the following section of this blog post to help them fix the bug in their site.
Users may choose to suppress mixed content warnings by adjusting browser security settings. Inside the Tools / Internet Options / Security / Internet Zone / Custom… dialog, the “Display mixed content” option can be set to “Disable.” This option will automatically block insecure content in secure pages without the annoyance of the prompt. In many cases the web page will not be seriously broken; in some cases, no user-visible change will occur, for instance, if the insecure content was a tracking pixel or metrics-tracking script.
Similar configurations can be made to the Intranet Zone and Trusted Zone settings. Within some organizations, it may be appropriate to set the Intranet zone option to “Enable,” because it is less likely that an attacker outside the organization could exploit Intranet sites containing mixed content. In contrast, while it might be tempting to set the “Trusted” zone setting to “Enable,” it’s important to remember that in the face of a DNS-poisoning or man-in-the-middle attack, even “trusted” HTTP traffic could be intercepted.
Note: There's one other important factor to keep in mind-- IE checks the Security Settings for the Zone of the insecure content, not the Security Settings of the Zone of the page. Intuitively, that's seems quite backwards, doesn't it? It certainly seemed surprising and wrong to me when I first learned about it.
However, if you think harder about it, it turns out that it makes perfect sense: you (the user) may know that you have a "safe" connection to a particular zone (say, the Intranet) and hence any content that is coming from that Zone can be transfered without HTTPS but remain secure (say, because your organization's firewall prevents tampering by external attackers). In contrast, if you were visiting a HTTPS page on your Intranet, and it tried to pull in insecure content from the Internet, it would be incorrect for the browser to say "Well, the outer page is trusted, so we'll let unprotected content from another source be mixed in."
For security and user-experience reasons, mixed content vulnerabilities should be fixed by the web developer. In principle, this is very simple: within a HTTPS page, never include a link to a HTTP-delivered resource.
One trick which might be useful is to use protocol-relative hyperlinks, of the form “//example.com/image.gif”. When the user visits a secure page containing such a reference (e.g. https://example.com/page.htm) the resulting URI will be evaluated as https://example.com/image.gif. On the other hand, if the user visits the same page using HTTP, the resulting URI will be evaluated as http://example.com/image.gif. In this way, site developers can easily build pages that work for either HTTP or HTTPS without introducing a mixed content vulnerability.
If you simply remove the SRC attribute from this tag (since it's not performing a download), you will find the problem goes away.
If you encounter a mixed content warning while working with your site, you may be able to use IE’s built-in developer tools to search for the insecure reference. However, it’s also possible that a HTTPS URL returned a redirect to an insecure resource, which could be difficult to determine by examining the DOM alone. The Fiddler web debugger can help troubleshoot the problem; simply follow these steps:
1> Start Fiddler
2> Clear the browser cache
3> Hit CTRL+F5 to reload the page
4> In Fiddler, click the Protocol column to sort by requests by protocol
6> Eliminate the use of those HTTP URLs or update any secure redirectors pointing to HTTP resources
By removing mixed content vulnerabilities, you can protect the integrity and privacy of the content on your secure pages, and avoid annoying your visitors with this security prompt.
Thanks for your help in securing the web!
@Mark: The IE9 Beta is out now: http://www.beautyoftheweb.com/
Hi I have stumbled upon an even weirder issue with mixed content warning. Check out the site https://ebankbps.pl everything is fine when i enter the url to the address bar or refresh the page. However when you go to http://www.bankbps.pl/bps24/ then click the second link in the center of the page, https://ebankbps.pl opens up in a new window. Now hover your mouse over the login text field and mixed content warning comes up. I would blame the popup script, however it does not happen when i enter the url normally or in any other browser.
@Karol: I'm not able to reproduce that problem in current builds of IE9. Using the "ScriptFree" plugin described in earlier comments, I see that the URL which is being treated by IE8 as mixed content is "about:blank".
Thanks for looking into it, i tried using ScriptFree but it crashed my browser when mixed content warning was about to show. And i also tried ie9 which works fine.
[EricLaw: Yeah, ScriptFree sometimes encounters this problem, which is one reason it's not a released project. If your machine is configured the same as mine, running IE as Administrator for debugging will allow ScriptFree to run without a crash]
Eric, first of all thanks for your post, it's of great use! And also thank you for answering to all our question. I tried most of the thing, and can't get where something is wrong. It happend immidiatly in the login page, and with Fiddler there aren't any HTTP non-connect messages.
here's the public address: www.regione.lazio.it/accreditamento
any hint or tip?
@Marco: You hit exactly the same issue as the last few folks; IE8 is constructing the following URL, which it believes is insecure:
This is fixed in IE9. To fix for IE8, change that URL from a relative URL to an absolute URL.
I am developing an intranet site for a client using struts2 and I am running into Mixed Content Warning in IE8. I have run your "Script Free" tool and it is pointed the mixed content to about:<path>/tab_close.gif. Can you please suggest a way to overcome this warning. I am using struts dojo tags to load the div in the jsp.
Thanks in advance
@viswa: As stated in virtually all of the comments, including the one that immediately precedes yours, the bug in question is fixed in IE9. To fix for IE8, change your image reference such that instead of using a relative URL, it uses an absolute URL.
As Whiner stated, I too am unable to fix this for trusted sites only. I use MSIE 8 under Win7 Enterprise x64 (not my choice) and have "enable mixed content" for my "trusted" zone. Nonetheless, many sites in this zone produce th "mixed content" prompt dialog. I don't wish to allow mixed content on all sites.
[EricLaw: As noted, the setting applies to the zone of the source of the insecure content, not the page that contains the references to that insecure content. You've reconfigured the wrong zone. Also, as I pointed out, the notion of using Trusted Sites as a cue to ignore mixed content misses the entire threat of how mixed content actually gets exploited.]
Thanks to your "scriptfree" tool I found that my issue was being caused by a reference to a local file from the web page. The message shows that the block mixed content refers to file:///C:/xyz/Temp/abc.jpg
Is there any way of referencing and displaying a local file on this page without the mixed content message appearing?
Eric, We've run into an interesting variation on this problem that doesn't obviously involve "about". Try visiting www.stewart.net/.../bug.html. No warnings, right? Open the F12 panel and navigate away from the page using the link. Now click the back button. We've been seeing spurious mixed mode warnings like:
SEC7111: HTTPS security is compromised by www.stewart.net/.../bg.png
That resource is referenced by an inline stylesheet:
It's not reliable. Sometimes it fires, sometimes it doesn't. Perhaps more importantly, the on-screen indications of mixed mode content do not appear. We only noticed this because we were watching the console.
@Jeff: There's a known bug in the IE9 F12 console where it shows a mixed content warning for a resource that wasn't actually blocked. You can tell that it wasn't blocked because there was no user-notification and the resource in question wasn't an image. The warning is innocuous as it's only in the console and doesn't affect functionality. I believe it's getting fixed in IE10.
@Nagaraj: Why are you convinced that the frame is the problem?
@Eric: There is no http reference in fiddler logs. We are getting 200 as http response for all request for this page. All request and response are through https only. Further the site throws no warning message when we work over http. The only suspect is about reference, about:blank. we zeroed in to this place after trying all options