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!
@ScottyB: You've hit the same problem that many folks seem to be hitting; there's a race condition where a relative URL is combined with the "about" protocol and is being deemed insecure.
SEC7111: HTTPS security is compromised by about:window_toolbar.png
SEC7111: HTTPS security is compromised by about:window_bg.png
SEC7111: HTTPS security is compromised by about:slideHue.gif
SEC7111: HTTPS security is compromised by about:slide.gif
SEC7111: HTTPS security is compromised by about:SatVal.png
@EricLaw: That has to be the speediest response from anyone I have ever seen. That was the clue we needed. Buried in that JS were indeed many things like this.Hslide.style.background="url(slideHue.gif)";. We added some JS to figure out the host protocol and paths, replaced everything with this.Hslide.style.background="url("+hostURL+"slideHue.gif)"; and all is well.
Thank you! Thank you! I will let the people we bought draw2d.js from know how to fix it.
@EricLaw: Can u plz have a look at the home page of this site https://www.axisdirect.co.in . When u click on opinion polls i get a https prompt. I've checked in httpwatch no http request is going from there. i've looked at all the above discussed scenarios but am not able to figure out the reason for this.Can u plz help me on this. Also when u click on refresh button of market mood same prompt comes.
@Dhaval: You have the same general problem as the last few folks; URLs are being combined incorrectly with the ABOUT: protocol.
SEC7111: HTTPS security is compromised by about:../framework/images/special_offers.jpg
SEC7111: HTTPS security is compromised by about:../framework/images/tools_and_features.jpg
Also, your homepage shows one other configuration problem:
HTML1114: Codepage utf-8 from (HTTP header) overrides conflicting codepage iso-8859-1 from (META tag)
@EricLaw: Thanks a lot for ur suggestion but can please explain me the last problem that u have mentioned. Do i have to set the header as utf-8 or iso-8859-1 and whether this can also cause the https prompt to occur?
@Dhaval: The codepage issue won't cause HTTPS problems. You can fix it by changing your META HTTP-EQUIV tag so that it properly indicates your charset is UTF-8, or by removing that META tag already.
The HTTPS problem is the same problem as encountered by the last few comments (read the comments before yours). It's a bug in IE that you can work around by using a fully-qualified path in your markup... instead of using e.g. SRC="../framework/images/special_offers.jpg" instead use SRC="www.axisdirect.co.in/.../special_offers.jpg", etc.
Hi Eric, With regards to the silent removal of the padlock (discussed earlier). I am getting this sympton on a Hilton Hotels web site. The site is www.glasgow.hilton.com/glasgowgiftvoucher
After picking dates and room etc. the last page is the page where I have to enter credit card details. As well as the padlock disappearing I notice that the site is trying to load content from px.admonkey.dapper.net, ad.yieldmanager.com, fls.doubleclick.net and many others.
I have complained to Hilton and asked if they would take my booking without a credit card but they insist that the site is secure, they say that the padlock not being there is irrelvant and the https shows it is secure. They say I must provide my card details or they will not take my booking.
My question is, in your opinion, is this site safe? If not can you give me some information as to why so that I can go back to them or my local Trading Standards office with a more detailed complaint?
Many thanks for any help or advice you can offer on this.
@Derek: If the lock isn't there, that means that not ALL of the content was delivered securely. Many websites make this mistake, which I first explained over five years ago in this post: blogs.msdn.com/.../410240.aspx. In the Hilton case, yes, it looks like the reservation page pulls in many different tracking/advertising URLs from insecure sources. I definitely wouldn't want to use this page from a public network.
Many thanks Eric this feedback is greatly appreciated.
Hi Eric, This mixed content warning is making me crazy! Here is the page that is giving me fits: www.drmyattswellnessclub.com/.../indexTEST.html
@Mark: Update your reference from download.macromedia.com/.../swflash.cab to HTTPS.
Looks like I might have it - there was another instance buried in a .js file So far so good...This certainly is an exquisitely frustrating issue for anyone trying to put together a website! Thanks for your help. - Mark
@Mark: You'll be happy to know that IE9's F12 Developer tools show the exact insecure URL in the console.
>You'll be happy to know that IE9's F12 Developer tools show the exact insecure URL in the console.<
That will be really handy! When can we look forward to seeing it?