Content from loopback addresses (e.g. 127.0.0.1) should not be considered mixed content

Fixed Issue #18003417

Details

Created
Jun 22, 2018
Privacy
This issue is public.
Reports
Reported by 14 people

Sign in to watch or report this issue.

Steps to reproduce

Check-in Instructions 

 https://microsoft.visualstudio.com/DefaultCollection/_git/os/commit/a4e77791177e91805614d61a3234cc03ea80f540

Conflict Contact

rajatj

Submitted by

rajatj

What is the issue?

In general if we load any sub-resource over http protocol on a page hosted over https protocol, Edge by default block the sub-resource download and shows a notification to the user. 

For interop reasons we need treat resources from localhost and loopback address as secure even are loading over http protocol on an https page.

How was the issue/bug found?

CSS has requested to service the bug in order to unblock
Coca Cola.

Quantify the impact of the issue - why do we need to
service this issue now?

 

In fact, this bug
is impacting enterprise customers that use software from Box.com.
Box.com has over 85K customers and is on track to do $600M this year;
they’re one of the largest content management companies.

Problem comes when the hosting page is 

https://box.com

(or
similar) but an iframe is pulling localhost content via local host
server.

Regression from RS3. We made a fix in RS3 for localhost
    but did not port it to the fetch layer.

Is the fix ready and what is it?

Fix is to treat resources loads over loopback and localhost as secure, so that Edge browser don’t block them by default

How was the fix Validated?

Repro provided by the customer:-

Host the attached content locally in IIS and then access the page using 127.0.0.1 (Edge Mixed Content.zip)

Actual

The error we saw at the Edge’s console is SEC7111: HTTPS
security is compromised by 
http://127.0.0.1

Expected:

No error warning

Regression risk level of the fix

Low. 

Has the fix been flighted in a RS5 flight?

Yes.

Flighted in WIP Fast 

17692 on 6/13. No issues so far.

DRT added

 

Do you have any data points that can be monitored to
ensure that the fix works or if there are adverse effects from the fix?


No

Does this fix need to be backported to TH2, RS1,
RS2, RS3 or prior releases (for SAC/LTSB customers)?

RS4 and RS3 only

QD signing off on this change

Fedek, WPT MCSN

How to validate/test for regressions
(required
for WSD pre-release validation)

We already flighted the fix and haven’t seen any regression. Also added the test coverage along with the fix.

Is this Product regression or Servicing regression?

Please
provide bug that caused the regression.

Product regression in RS3.

Release notes (if Rel Note field == Yes)

 No

According to the spec, content from loopback addresses should no longer be treated as mixed content even in secure origins. See: - https://github.com/w3c/webappsec-mixed-content/commit/349501cdaa4b4dc1e2a8aacb216ced58fd316165 - https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy In other words, e.g. fetch('http://127.0.0.1:1234/foo/bar') on a HTTPS site should be allowed without triggering the mixed content blocker. Note Chrome (and soon Firefox) only whitelist ‘127.0.0.1’ and '::1’. See: - https://chromium.googlesource.com/chromium/src.git/+/130ee686fa00b617bfc001ceb3bb49782da2cb4e - https://bugzilla.mozilla.org/show_bug.cgi?id=903966

Attachments

0 attachments

    Comments and activity

    • Microsoft Edge Team

      Changed Assigned To to “Rajat J.”

      Changed Steps to Reproduce

      Changed Assigned To from “Rajat J.” to “Tony Z.”

      Changed Steps to Reproduce

      Changed Status to “In progress”

      Changed Assigned To from “Tony Z.” to “Robert Z.”

      Changed Assigned To from “Robert Z.” to “Taeksoo J.”

      Changed Assigned To from “Taeksoo J.” to “Prabs C.”

      Changed Status from “In progress” to “Fixed”

      Changed Assigned To from “Prabs C.” to “Robert Z.”

      Changed Assigned To from “Robert Z.” to “Prabs C.”

    You need to sign in to your Microsoft account to add a comment.

    Sign in