A customer recently wrote to ask whether there was any way to suppress the red “/!\ Not Secure” warning shown in the omnibox when IE Mode loads a HTTPS site containing non-secure images:

Notably, this warning isn’t seen when the page is loaded in modern Edge mode or in Chrome, because all non-secure “optionally-blockable” resource requests are upgraded to use HTTPS. If HTTPS upgrade doesn’t work, the image is simply blocked.

The customer observed that when loading this page in the legacy Internet Explorer application, no “Not Secure” notice was shown in IE’s address bar– instead, the lock icon just silently disappeared, as if the page were served over HTTP.

Background: There are two kinds of mixed content, passive (images, css) and active (scripts). Passive mixed content is less dangerous than active: a network attacker can replace the contents of a HTTP-served image, but only impact that image. In contrast, a network attacker can replace the contents of a HTTP-served script and use that script to completely rewrite the whole page. By default, IE silently allows passive mixed content (hiding the lock) while blocking active mixed content (preserving the lock, because the non-secure download was blocked).

The customer wondered whether there was a policy they could set to prevent the red warning for passive mixed content in Edge’s IE Mode. Unfortunately, the answer is “not directly.”

IE Mode is not sensitive to the Edge policies, so only the IE Settings controlling mixed content apply in this scenario.

When the IE Mode object communicates up to the Edge host browser, the security state of the page in IEMode is represented by an enum containing just three values: Unsecure, Mixed, and Secure. Unsecure is used for HTTP, Secure is used for HTTPS, and Mixed is used whenever the page loaded with mixed content, either active or passive. As a consequence, there’s presently no way for the Edge host application to mimic the old IE behavior, because it doesn’t know whether IEMode displayed passive mixed content, or ran active mixed content.

Because both states are munged together, the code that chooses the UI warning state selects the most alarming option:

     content_status |= SSLStatus::RAN_INSECURE_CONTENT;

…and that’s status is treated as a more severe problem:

SecurityLevel kDisplayedInsecureContentWarningLevel = WARNING;
SecurityLevel kRanInsecureContentLevel = DANGEROUS;

Now, even if the Edge UI code assumed the more benign DISPLAYED_INSECURE_CONTENT status, the browser would just show the same “Not secure” text in grey rather than red– the warning text would still be shown.

In terms of what a customer can do about this behavior (and assuming that they don’t want to actually secure their web content): they can change the IE Mode configuration to block the images in one of two ways:

Option #1: Change IE Zone settings to block mixed content. All mixed content is silently blocked and the lock is preserved:

Option #2: Change IE’s Advanced > Security Settings to “Block insecure images with other mixed content”, you see the lock is preserved and the IE-era notification bar is shown at the bottom of the page:

Stay secure out there!

-Eric

Impatient optimist. Dad. Author/speaker. Created Fiddler & SlickRun. PM @ MSFT '01-'12, and '18-, working on Office, IE, Edge, and Web Protection. My words are my own, I do not speak for any other entity. View more posts