We have previously written about the pointless and confusing ‘Do you want to view only the webpage content that was delivered securely‘ message in IE 8. It is displayed by default when a secure web page attempts to use non-secure content such as images, javascript or CSS. That post has been so popular that it attracts 40% of the traffic to this blog.

The IE 8 mixed content dialog is pointless because 99.9% of web users just want it to go away and let them get on with what they were doing. For the 0.1% of web surfers who do care, it is confusing because of the way it is worded:

The blog post described how you can disable this warning and from the comments it looks like many users are now doing this.

Even if you do this, IE still silently performs the check and hides the re-assuring padlock icon that you normally see on HTTPS pages:

This could be disturbing for anyone on a checkout page who is about to enter their credit card details. So if you’re web site developer you really need to avoid using mixed content – even for users who have disabled this warning. Firefox has the mixed content warning turned off by default. Let’s hope Microsoft do the same turn in the next version of IE.

You can normally fix the mixed content warning by ensuring that all the content on a secure page is served up with HTTPS. In HttpWatch you can quickly check a page by using a forced refresh to look for URLs starting with ‘http;’ :

However, a customer contacted us recently because they were still getting the mixed content warning even though they had no HTTP URLs on their secure page. After some investigation it was found that this commonly used javascript technique was causing the problem:

// Causes mixed content message in IE on a secure page
document.write("<script id="__ie_onload" src="javascript:void(0)"></script>");
document.getElementById("__ie_onload").onreadystatechange = function()
{
     if (this.readyState == "complete") domReady();
};

It’s a trick used to emulate a DOMContentLoaded event in IE.  A security warning occurs because of the use the “javascript:” protocol even though no download occurs.

The fix is to use //: in the src attribute in the same way as popular javascript libraries such as jQuery and prototype. This does cause a harmless ERROR_INVALID_URL entry in HttpWatch, but it avoids the mixed content message:

// Does not cause a mixed content message in IE on a secure page
document.write("<script id="__ie_onload" src="//:"></script>");
document.getElementById("__ie_onload").onreadystatechange = function()
{
     if (this.readyState == "complete") domReady();
};

In a previous blog post, we talked about the problem of using HTTP based resources, such as images, on a secure HTTPS page. Internet Explorer interrupts the download and displays a confirmation dialog whenever it detects the use of mixed content on a secure page.

In IE 7 and ealier, this dialog would cause annoyance to users but generally didn’t cause any other significant problems. This was because it was worded in such a way that most users would click on the Yes button and allow non-secure content to be downloaded.

However, the wording in the IE 8 version of this dialog has changed:

To download the content a user would now have to click on the No button. As we know, most people using the web only scan text and avoid reading it if at all possible! They will usually go for the Yes button if there is not an OK button.

Some sites are going to find that their secure pages in IE 8 have the following problems:

• Any non-secure HTTP image beacons used for analytics data gathering will often be ignored
• The page may not display or even work correctly if it relies on non-secure images, CSS or Javascript

Therefore, avoiding mixed content on HTTPS pages is even more important now that IE 8 has been released. It often becomes an issue when using third party services such as analytics or Content Delivery Networks (CDN). For example, we avoided the use of Google hosted Ajax libraries on our site until Google added HTTPS support.

As mention in the previous blog post, an IE user you can disable this warning by:

1. Going  to Tools->Internet Options->Security
2. Select the Security tab
3. Click on the Internet zone icon at the top of the tab page
4. Click the Custom Level button
5. In the Miscellaneous section change Display mixed content to Enable
6. Repeat steps 1 – 5 for the Local intranet and Trusted sites zones

However, if you are developing a web site you can’t expect your visitors to do this. It is better to fix the cause of the problem so that the warning is not displayed by default in IE 8. The only way to do this warning is to ensure that your HTTPS pages only access embedded resources using the HTTPS protocol. You can do this by following these steps:

1. Use a sniffer like HttpWatch that supports HTTPS and shows files being read from the browser cache. The free Basic Edition is sufficient for this because you only need to see the URLs being accessed.
2. Access the page causing the problem and click No when you see the security warning dialog.
3. Any HTTP resources shown  in the HttpWatch window are the source of the problem; even if they loaded directly from the browser cache and didn’t cause a network round trip:
4. If you don’t initially see any HTTP based resources, try refreshing the page because a non-secure image may have been retrieved from the IE or Firefox image cache

EDIT #1: If you are a web developer trying to track down why your page causes this warning please also take a look  at http://blog.httpwatch.com/2009/09/17/even-more-problems-with-the-ie-8-mixed-content-warning/ where we cover some javascript snippets that can also trigger this warning. The comments section of both of these posts also contain useful information where people have found and solved related issues.

EDIT #2: Updated instructions to apply the change to all network zones

A common question we hear is “Can parameters be safely passed in URLs to secure web sites? ” The question often arises after a customer has looked at an HTTPS request in HttpWatch and wondered who else can see this data.

For example, let’s pretend to pass a password in a query string parameter using the following secure URL:

https://www.httpwatch.com/?password=mypassword

HttpWatch is able to show the contents of a secure request because it is integrated with the browser and can view the data before it is encrypted by the SSL connection used for HTTPS requests:

If you look in a network sniffer, like Network Monitor, at the same request you would just see the encrypted data going backwards and forwards. No URLs, headers or content is visible in the packet trace::

You can rely on an HTTPS request being secure so long as:

• No SSL certificate warnings were ignored
• The private key used by the web server to initiate the SSL connection is not available outside of the web server itself.

So at the network level, URL parameters are secure, but there are some other ways in which URL based data can leak:

1. URLs are stored in web server logs – typically the whole URL of each request is stored in a server log. This means that any sensitive data in the URL (e.g. a password) is being saved in clear text on the server. Here’s the entry that was stored in the httpwatch.com server log when a query string was used to send a password over HTTPS:

   
2009-02-20 10:18:27 W3SVC4326 WWW 208.101.31.210 GET /Default.htm password=mypassword 443 ...


   It’s generally agreed that storing clear text passwords is never a good idea even on the server.

2. URLs are stored in the browser history – browsers save URL parameters in their history even if the secure pages themselves are not cached. Here’s the IE history displaying the URL
   parameter:

   

   Query string parameters will also be stored if the user creates a bookmark.

3. URLs are passed in Referrer headers – if a secure page uses resources, such as javascript, images or analytics services, the URL is passed in the Referrer request header of each embedded request. Sometimes the query string parameters may be delivered to and stored by third party sites. In HttpWatch you can see that our password query string parameter is being sent across to Google Analytics:
   

Conclusion

The solution to this problem requires two steps:

• Only pass around sensitive data if absolutely necessary. Once a user is authenticated it is best to identify them with a session ID that has a limited lifetime.
• Use non-persistent, session level cookies to hold session IDs and other private data.

The advantage of using session level cookies to carry this information is that:

• They are not stored in the browsers history or on the disk
• They are usually not stored in server logs
• They are not passed to embedded resources such as images or javascript libraries
• They only apply to the domain and path for which they were issued

Here’s an example of the ASP.NET session cookie that is used in our online store to identity a user:

Notice that the cookie is limited to the domain store.httpwatch.com and it expires at the end of the browser session (i.e. it is not stored to disk).

You can of course use query string parameters with HTTPS, but don’t use them for anything that could present a security problem. For example, you could safely use them to identity part numbers or types of display like ‘accountview’ or ‘printpage’, but don’t use them for passwords, credit card numbers or other pieces of information that should not be publicly available.

You can check SSL/TLS configuration our new SSL test tool SSLRobot . It will also look for potential issues with the certificates, ciphers and protocols used by your site. Try it now for free!