4

We have an in-house (.Net) application that runs on our corporate desktops. It runs a small web server listening on for HTTP requests on a specific port on localhost. We have a separate HTTPS website that communicates with this application by setting the ImageUrl of a hidden image to the URL of the - this invokes an HTTP request to localhost, which the application picks up on and actions. For example, the site will set the URL of the image to:

http://127.0.0.1:5000/?command=dostuff

This was to work around any kind of "mixed content" messages from the site, as images seemed to be exempt from mixed-content rules. A bit of a hack but it worked well.

I'd seen that Chrome was making moves towards completely blocking mixed content on pages, and sure enough Chrome 87 (currently on the beta channel) now shows these warnings in the Console:

Mixed Content: The page at 'https://oursite.company.com/' was loaded over HTTPS, but requested an insecure element 'http://127.0.0.1:5000/?command=dostuff'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html

However, despite the warning saying the request is being automatically upgraded, it hasn't been - the application still gets a plain HTTP request and continues to work normally.

I can't find any clear guidance on whether this warning is a "soft fail", and whether future versions of Chrome will enforce the auto-upgrade to HTTPS (which would break things). We have plans to replace the application in the longer term, but I'd like to be ahead of anything that will suddenly stop the application from working before then.

Will using HTTP to localhost for images and other mixed content, as used in the scenario above, be an actual issue in the future?

KenD
  • 5,280
  • 7
  • 48
  • 85
  • What's your actual question? – DylanSp Oct 28 '20 at 14:07
  • @DylanSp: I've updated the post. I guess what I'm asking is: why is Chrome saying it's upgrading the HTTP request to HTTPS when it isn't, and given that it seems to be a "soft warning" will this start to become an actual issue for us in the future? – KenD Oct 28 '20 at 15:46
  • Is Chrome the only browser which is used in that environment? – Binarus Oct 29 '20 at 13:15
  • @Binarus: yes, it's the only one we support for our corporate users – KenD Oct 29 '20 at 16:33
  • Would you be happy with a possible solution to the problem instead of an answer to your question? – Binarus Oct 29 '20 at 18:57
  • @Binarus: Thanks, but we already have a plan to replace the application in the longer term, and won't need this way of communicating between browser and desktop application. However, /if/ this turns out to be a breaking issue - rather than just a warning that ultimately doesn't impact functionality in the short-to-medium term - then we'll need to redraw our development roadmap! – KenD Oct 29 '20 at 19:52
  • I have asked because I have an idea how to solve the problem without changing the application. Probably nobody can foresee whether and when Google makes this issue a real problem (I already have experienced a similar situation with Firefox a few months ago, with warnings that normal users noticed and were worried by). Back to my idea: What about installing an additional (reverse) proxy server on your users' PCs which pulls the data from your application via HTTP, but passes it on via HTTPS? Or a more lightweight SSL wrapper? That way you could remedy the warning without changing your app. – Binarus Oct 29 '20 at 21:29
  • Yeah I can see that working, although it will mean quite a bit of effort in installing the local proxies - at this stage, I'm really just trying to find out IF any of this will be necessary. The "error" at the moment doesn't actually cause any problem, but who knows if Google will flip a switch in Chrome 88 or later that will enforce HTTP upgrading? – KenD Oct 30 '20 at 08:50
  • And that is which I guess nobody can answer (unless members of the Google Chrome development team are around here *and* are allowed to talk about such internals, which probably is both unlikely) :-) – Binarus Nov 01 '20 at 16:35

2 Answers2

2

This answer will focus on your main question: Will using HTTP to localhost for images and other mixed content, as used in the scenario above, be an actual issue in the future?

The answer is yes.

The blog post you linked to says:

Update (April 6, 2020): Mixed image autoupgrading was originally scheduled for Chrome 81, but will be delayed until at least Chrome 84. Check the Chrome Platform Status entry for the latest information about when mixed images will be autoupgraded and blocked if they fail to load over https://.

That status entry says:

In developer trial (Behind a flag) (tracking bug) in:
Chrome for desktop release 86
Chrome for Android release 86
Android WebView release 86
…
Last updated on 2020-11-03

So this feature has been delayed, but it is coming.

Brian Drake
  • 346
  • 1
  • 8
  • Thanks - unfortunately I'm getting `Permission denied` when following the link to the "tracking bug" in the status entry, so I'll keep checking every Canary release to see if things are changing. – KenD Nov 04 '20 at 17:08
1

Going through your question and all comments - and putting myself in your shoes, I would do the following:

  1. Not messing with either the currently working .Net app/localhost server (HTTP), nor the user-facing (HTTPS) front-end.
  2. Write a simple/cheap cloud function (GCP Cloud Function or AWS Lambda) to completely abstract away your .Net app from the front-end. Your current HTTPS app would only call the cloud function (HTTPS to HTTPS - not having to pray anymore that Google will not shut-down mixed traffic, which will happen eventually, although nobody knows when).
  3. The cloud function would simply temporarily copy the image/data coming from the (insecure) .Net app to cloud storage and then serve it straight away through HTTPS to your client-side.
Marc
  • 2,183
  • 2
  • 11
  • 16
  • The keyword here is “insecure”. You’re proposing a wrapper running on an *external server* that accesses software running on individual corporate *desktops*? – Brian Drake Nov 04 '20 at 08:02
  • There is a business decision to be made here. The .Net legacy side is currently intrinsically insecure (serving HTTP only). Either it gets rewritten to serve securely or it gets wrapped in a secured layer - which I proposed. The current way is worse, from a security point of view (corporate desktop exposed directly to the WWW through mixed traffic). My assumption as well was of course that these images they want to pass on to the client-side are not classified as confidential. Now, you did give them a good answer to their question but I just wanted to share a potential practical way forward. – Marc Nov 04 '20 at 08:18
  • “Now, you did give them a good answer to their question” Good, because you didn’t answer the question at all. Regarding your recommendations, OP said they already have a plan to get rid of this app entirely, which is obviously the best idea of all, and they can speed that up if needed. In the meantime, there are other ideas, like a Chrome extension that is only accessible by specific URLs, or a *local* wrapper (either on the desktop or on the corporate server). I understand these ideas have their own issues, but at least mention them before discussing an idea like the one in your post. – Brian Drake Nov 04 '20 at 08:37
  • Noted Brian. Appreciate your feedback. – Marc Nov 04 '20 at 08:42