Hacker News Reader

Comment by edejong | Hacker News Reader

The reason the developers didn't use CORS is because active mixed content isn't allowed. You simply cannot call 'http://localhost' from a https domain. For a medical SaaS application which needed to communicate via USB I created a self-signed certificate during installation and added it to the trust store to be able to call active content on localhost. Previously, we used NPAPI (which, when used correctly was more secure than the current plugin architecture), but that got deprecated.

Ask yourself why many developers need this path. The reason is that creating plugins for various web-browsers is a very expensive ordeal, with Firefox and Chrome having a completely different ecosystem. Moreover, in my opinion the plugin ecosystem is less secure than having good engineers take the localhost path (with challenge-response token authentication and origin hostname validation, obviously).

View on HN

This is discussed in the post text, but happy to elaborate here in more detail here! Here is the patch links from Firefox[0] and from Chrome[1] which they specify that active mixed content policies do not apply to the localhost, because the w3c specification was updated to specifically allow this behaviour[2]. You might have to use 127.0.0.1 directly. So yes, it is allowed.

If for some reason that doesn't work for your app, the post also mention two secure alternatives: the native client can install a self-signed cert, or you can use a browser extension with the native messaging API. You touched on this too!

My point here is not the specific example solution -- there's lots of alternatives and yes it depends on the situation and browser support requirements. But NONE of them are a reason to allow requests from every origin.

[0]: https://bugzilla.mozilla.org/show_bug.cgi?id=903966

[1]: https://chromium.googlesource.com/chromium/src.git/+/130ee68...

[2]: https://github.com/w3c/webappsec-mixed-content/commit/349501...

I see it is fixed now. I thought up this work-around back in 2014, when NPAPI was phased out. Spotify and another large player came up with similar solutions.

Totally. I do get the constraints and I imagine Zoom had similar thinking here. The image approach, although hacky, can even be secure as-is if they need it for backward-compatibility but it needs to check the headers and not honour requests with the wrong value.

I kind of like the ingenuity of the approach. Never occurred to me to use non-active content.

It seems that the Chromium patches are from 2016, so presumably this would still break older Chrome users?

2016 is in the 50s, and this[1] claims that version <67 has single-digit usage share.

[1] https://www.w3schools.com/browsers/browsers_chrome.asp

I think that Chrome allows calling http://localhost from https domain. Other browsers should fix that instead of every application installing their custom certificates into trust store.

Installing trust store certificates for these purposes is asking for trouble. Sure, if the private key is unique per installation it theoretically should be fine, but in reality it can be hard to gather enough entropy to be satisfiably unpredictable, and it's very easy to get this wrong. It's worth noting that there isn't a solid way to limit your CA certificate in the trust-store to the domains you intend to use it with https://security.stackexchange.com/questions/31376/can-i-res...

Can't you just install a specific self-signed certificate for a single domain instead of a CA certificate?

Yes, you can and you should do that.

> in reality it can be hard to gather enough entropy to be satisfiably unpredictable

I think this is a myth, especially on desktop/laptop PCs - a few hundred bytes of entropy at system boot initialize the kernel CSPRNG, which can then generate countless gigabytes of cryptographic-quality randomness on demand.

Sorry, I might initially have caused this mess, thinking browsers would fix it sooner than later.

Well, you need your software to work now, hard to blame you :)

I thought about this problem and there are two workarounds. First workaround is to get agreement with major CA who would allow you to issue a valid certificates for users. So it's like user installs your software, generates private key and you generate signed certificate for that key on your server. I think that plex does that, but it's probably extremely hard and fragile scheme. Second workaround would be to proxy traffic from your localhost server to your remote server. Remote server would present valid certificate for something like local.yourcompany.com and would decrypt traffic and translate it back to your localhost server. Same with response. So you're doing encryption with remote server and never leak your private key. I'm not sure if CA would be happy with that implementation, but technically I believe it's not a key compromise.

The first workaround also crossed my mind, but it had a couple of drawbacks. First, it required contractual work with a CA and they can easily say: it's not our problem, it is the browser. The amount of time required to set this up would be around a year, maybe more. Also, like you said, it is fragile.

The second workaround I didn't think about. Do you mean we'd change the resolver to resolve 'local.yourcompany.com' to 127.0.0.1 on the local machine? That would work, but would introduce quite some extra latency and add some fragility.

Wouldn't part of this be solved by using a real domain that resolves to 127.0.0.1 instead of localhost? Then you can get a real cert and embed it in the client to make local requests work properly?

> You simply cannot call 'http://localhost' from a https domain.

That’s simply wrong. You have outdated information. Unless you don’t consider Firefox, Chrome, IE, and Edge to matter. https://chromium.googlesource.com/chromium/src.git/+/130ee68...

https://developer.microsoft.com/en-us/microsoft-edge/platfor...

Safari still has an open issue I think. But that’s no surprise since Apple has demonstrated they’re suckitude at software security and development in general.

This is not true. We tested this on April 2019. Chrome works with http://localhost. Firefox does not => https://bugzilla.mozilla.org/show_bug.cgi?id=1488740

Oddely, the issue was updated today after months of inactivity. Maybe they became aware of their part of responsibility in what happened to Zoom?

Reply on news.ycombinator.com