IEInternals

A look at Internet Explorer from the inside out. @EricLaw left Microsoft in 2012, but was named an IE MVP in '13 & an IE userAgent (http://useragents.ie) in '14

Handling Mixed (HTTPS/HTTPS) Content

Handling Mixed (HTTPS/HTTPS) Content

Rate This

Update: IE9 includes improved handling of Mixed Content. Click to learn more...

Background

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.

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

Suppressing Mixed Content Warnings (for end-users)

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

Preventing Mixed Content Warnings (for web developers)

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.

 

Another common problem (described by lots of folks in the comments) is caused by using JavaScript protocol links for the SRC attribute of SCRIPT tags. In IE8 and below, the following SCRIPT tag will cause a mixed-content warning:

 

    <script type="text/javascript" id="contentloadtag" defer="defer" src="javascript:void(0)">

  

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

5>     Determine which URLs have been delivered using HTTP.  Also, search for any instances of SRC="javascript: in your markup.

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!

 

-Eric Lawrence

  • Eric, thanks so much for your offer of help.  Everything is still on development right now, so I don't have a page to direct you do.  We may have figured it out thought.  Question....do both the secure and non-secure servers have to be configured to be secure and non-secure for this to work?  Someone else said they got, from this article, that the // will take where they are supposed to go from the last protocol from the browser?  Any of that true?

    If not, any ideas why this is not working?  Here is the scenario:

    Application resides on secure server with domain of https://app.domain.com.  The app has been designed to have the same look and feel as the website, which resides on http://domain.com where domain.com is the same for both.  So as not to store and maintain site images and style sheets in multiple locations, the images and style sheets are all maintained on the non-secure server, http://domain.com and are linked from the secure site https://app.domain.com using the full path currently.

    The typical use is for visitors to start off on the non-secure site, and click one of the secure links.  When this happens in IE, the visitor receives the message asking if they want to download the non-secure content.

    When the http:// was replaced with //, and we go to the secure page, the visitor is not prompted; the page is simply loaded without the non-secure content.

    It would also be nice for browsers to recognize that the server in question is the same domain, and not joedreamland.com or something!  *grin*

    Any help you can provide would be greatly appreciated.  

    Thanks,

    Suzanne

  • Suzanne: A URL without a scheme (e.g. "http:") specified at the front is considered "protocol-relative." In HTML pages, the URL is relative to (and hence combined with) either the URL of the containing page, or to the URL specified in the BASE tag, if such a tag is present in the HTML HEAD. So, if you're on https://foo/ and you have a reference to //bar/, then that URL is really "https://bar/". However, if you load the same page on http://foo/, then //bar/ then refers to "http://bar/".  So, yes, generally speaking, if you want to use protocol-relative URIs, then you must ensure that your destination resource is available using the same protocol(s) as the HTML page that uses those resources.

    You can use a Web Debugger like Fiddler (www.fiddler2.com) to understand what your HTTP/HTTPS requests are returning from the server.

    In your scenario, the server in question is not "same-origin." You should read blogs.msdn.com/.../private-domain-names-and-public-suffixes-in-internet-explorer.aspx to understand why that is.

  • Hi Eric,

    Thanks, as always, for your prompt response.  Yes, I understand that, and appreciate the link.  I was afraid there would be no way around this.  Unfortunately, clients many times have to purchase SSL's for this.  Seems pretty silly to have to purchase a licence to make a server secure when it doesn't really need to be, and in actuality, is only being done to stop IE from asking the user about mixed content!

    Any idea how IE9 will handle mixed content?

    If you have any input, please let pass on the many issues this causes, especially in the case such as ours, where we simply do not want to maintain non-secure shared files such as images and style sheets in more than one place.

    Thanks again,

    Suzanne

  • Suzanne, I think you may have a few misunderstandings-- if you don't need your page to be secure, then don't deliver it over HTTPS to begin with! In contrast, if you do need the page to be secure, then you should deliver all of the content over HTTPS.

    Certificates are not necessarily expensive, and some CAs offer certificates for under $20 per year.

    We haven't yet announced IE9's changes to Mixed Content handling, but it's worth mentioning that *all* browsers, including IE9, will remove the lock icon when a HTTPS-delivered page contains insecurely-delivered content.

  • What happens when you would like to use a javascript addon like "addtoany" they offer both a http:// and https:// version of their code. Is there a way for you to check if the page is loading with http:// and load the url with http:// and if the user is on the https:// version of your site (ie. they are logged in) displays the https:// version of their code snippet?

    Summary: looks for some code that would check if the user is on your http:// or https:// version of your site and to load the correct off site url.

  • @Jasmel: I either don't understand your question, or I answered it already. If you do something like this:

    script src="//addtoany.com/whatever.js"

    Then you will find that if your hosting page is HTTPS the request will be made using HTTPS, or if your hosting page is HTTP then the request will be made with HTTP.

  • Is "javascript:void(0)" considered "unsecured" for any particular reason, or is it simply an oversight? Are we going to see this addressed in IE 9, or is this something we're going to gradually see developers pick up on?

  • @Alun: javascript:void(0) is no longer treated as insecure in the IE9 Platform Preview Builds. When IE9 Beta is released, there will be a blog post explaining all of the changes in IE9 when it comes to mixed content.

  • Eric, thanks again for the comments.  Sorry for the delay, have tried to post this several times without any luck, maybe this time will work!  ;-)

    Ok, let me try again to explain what we are doing.  I do understand when content should be sent securely or unsecurely, and that is exactly what is happening in a sense.

    We have a website, basically static, sitting where it should, on an unsecure server.  The images and style sheets are there, as they should be.  We also have an application, which the client wants to look just like the website, using the same images and style sheets, but, for the right reasons, it is sitting on a secure server. There are links from the static website to the various secure applications.

    As a web developer, I don't want to have to maintain TWO copies of my images and style sheets; I don't want to have to remember nor take the time to make changes to two copies of images and style sheets when there may be changes to the style of the site, etc.  SO, we link FROM the secure server/application to the unsecure server/website for the images and style sheets.

    Does that help?  I know that this is done quite frequently, and is not ill thought of by most, although I am sure some may not think it ideal.

    I do understand that this can be iffy, but we are using the same domain, the secure sever is actually a subdomain of the website's domain; secure=sub.domain.com and unsecure=domain.com.  That should count for something.  As I mentioned before, it isn't like we are sending them to some off the wall domain, like joesbarandgrill.tv or the like!  ;-)

    Now, with all that said, from your comments this last time, I should have two copies of all of the shared files.  As the person maintaining those files, I say there has to be a better way to deal with this!  *grin*

    Hope that helps.  And with that, if you have other suggestions, they are most welcome!  Thanks for your help, wisdom, and for being here for us, and thanks for the heads up on IE9.

    Thanks!

    Suzanne

  • @Suzanne: From your comment, it's plain that you don't understand what makes a server secure, and why mixed content has the effect of "tearing open" the secure envelope provided by HTTPS. I covered the topic a few years ago here: blogs.msdn.com/.../410240.aspx, and reiterated myself in this post. This has nothing to do with what the domain names are-- only what protocols are used to deliver content.

    If you want a HTTPS page to remain secure, you must include stylesheets and scripts from HTTPS sites only. Using HTTP content in a HTTPS page means that your "secure" page is not secure any longer.

    You don't need "two copies" of the shared files-- you can have one server that delivers both secure and insecure content, and simply have two urls (one HTTP and one HTTPS) that points to that same server and file.

  • I have been tearing my hair out trying to correct whatever is causing this mixed content warning - I have looked high and low for any instance of a http path, and also looked for anything untoward re: src= problems as has been described in your article. I can find nothing amiss... but perhaps I'm just missing it. I would be grateful if you would look at www.drmyattswellnessclub.com and tell me what I am missing. I am a nurse, not a code-writer. This kind of problem makes us crazy here and takes vital time away from my real job - patient care! Your (or anyone's) help will be appreciated.

  • On which page specifically do you see a warning-- the homepage itself?

    SEC7111: HTTPS security is compromised by download.macromedia.com/.../swflash.cab

    You should remove the VERSION attribute on that URL and change the HTTP to HTTPS.

  • Hi Eric - thank you for your help. The mixed content warning comes up on all our pages. It also comes up on www.drmyattswellnessclub.com/top_includeWCnew1PTABLED.htm which is a fundamental element to all our pages. This is as far back as I can track the problem - I don't know where the swflash.cab element is  - it is not something that I have ever (knowingly) built into our page... I don't see where it shows up.

  • @Mark: The content in question is the installer for Adobe Flash. It's used in your "peel corner" OBJECT tag which you've named "eselcornerSmall"

  • Hi Eric,

    i tryed the below example mentioned in the forum

    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.

    but its not working bro as you  said it was going to https://    but i still receive the same bug.

    if any solution that would make my client happier.

    D.Naveen Rahul

Page 5 of 9 (128 items) «34567»
Leave a Comment
  • Please add 8 and 5 and type the answer here:
  • Post