Content from loopback addresses (e.g. 127.0.0.1) should not be considered mixed content
Fixed Issue #11963735
Details
- Author
- Birunthan M.
- Created
- May 10, 2017
- Privacy
- This issue is public.
- Found in
- Standard affected
- Secure Contexts
- Fixed in build #
- 16.16246
- Reports
- Reported by 16 people
Sign in to watch or report this issue.
Steps to reproduce
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
Comments and activity
-
Changed Steps to Reproduce
-
Microsoft Edge Team Changed Assigned To to “Steven K.”
Changed Assigned To to “Venkat K.”
Changed Assigned To from “Venkat K.” to “Ali A.”
Changed Assigned To from “Ali A.” to “Rajat J.”
Changed Status to “Confirmed”
Changed Status from “Confirmed” to “In progress”
Changed Status from “In progress” to “Fixed”
-
Has there been discussion of backporting this fix in a security update for IE11? In order to migrate to this model, we would need it to be supported across all major browsers, and IE11 looks like it’s becoming the sticking point.
-
Does “FIXED, NOT YET FLIGHTED” mean this issue will be fixed in a future release of Edge? Is there a particular version that will contains the fix?
-
#16110645 was closed as a duplicate of this bug with an indication that the bug was solved in Edge 16245. However, this bug report is still listed as "Fixed, Not Yet Flighted". Please advise what that means…has the intended fix been released or not?
-
Apologies for the lack of update to this issue. There’s a bug in the logic and fields we search on to automatically update the public bug status in some combinations.
This bug is closed and released. We shipped it with the Windows 10 Fall Creators update (1709). Again apologies this bug wasn’t automatically update to report the correct status.
-
Jason M. - Appreciate the follow-up. However, I would urge the Edge Team to review the issue again. My understanding is that the Windows 10 Fall Creators update (1709) introduced this bug rather than resolving it.
-
I agree. I have tested this issue with the latest version of Edge, but am still seeing the SEC7111: HTTPS security is compromised error. Jason M., you may want to review this ticket.
-
This issue is not fixed in 1803. We get the same warning (SEC7111) when calling http://127.0.0.1:8111/load_and_zoom? from https://www.openstreetmap.org
- Microsoft Edge Team
Changed Steps to Reproduce
Changed Assigned To to “Rajat J.”
Changed Status from “Fixed”
-
Thanks all for the feedback on this. We reviewed again, this time using jQuery for an XHR request and we can see that over the new Fetch networking stack with XHRs, this is indeed still an open issue. Coding is happening now for the next release and we will review for back level servicing also.
Thanks again. - Microsoft Edge Team
Changed Assigned To from “Rajat J.” to “Angelo L.”
Changed Status to “Fixed”
-
Is there an estimated release date for this fix? I’m nearing release of an application that is currently jumping through hoops to work around this issue and would like to be able to remove my work around.
-
This fix is now flighting in the most recent Windows Insider Preview builds (17692+). Please test your applications against this build and provide us feedback so that we can collect data about the fix for servicing consideration.
Many thanks for your feedback so far.
-
I updated to the Insider Preview (Windows 10 Enterprise) and it is working great. Thanks!
Edge details:
Microsoft Edge 43.17704.1000.0 -
Based on flighting information, this fix has been approved for both our April 2018 and October 2017 releases of Windows 10.
Failing any issues we are yet to find, users on the April update who check for updates manually will get this fix the first week of August. Users on the October 2017 update who manually check will be sent the fix in the last week of August.
This will also be included in a mandatory security update in September for users on both releases.
Thanks again for your help in bringing this to our attention and your testing feedback.
Jason
-
Asking this again in 2018, is there any possibility to port back for IE11?
-
Has this fix been officially implemented as of the Fall Creators Update (1709) or the April 2018 Update (1803)?
I can see in Jason’s message that it was expected to be fixed, but would appreciate clarification on whether it actually happened or not.
This particular bug prevents secure Progressive Web Apps (aka UWP Hosted Web Apps) from communicating with localhost resources, because they use Edge under the hood. As you can imagine, this could be a significant limitation in enterprise environments, where OS updates don’t happen nearly as quickly/frequently as they do for individual users.
(P.S. I can’t wait until Edge updates are decoupled from Windows udpates. I believe this is a major factor in why this browser isn’t widely adopted like Chrome/Firefox.)
-
Microsoft:
was or not delivery this fix in October 2018?
thanks,
Diego
You need to sign in to your Microsoft account to add a comment.
Sign in