As discussed in crbug.com/378566, Chrome currently allows connecting to unsafe WebSockets on localhost. So just use a WebSocket to communicate from your HTTPS hosted page to your local server.

And yes, you definitely should whitelist access based on the origin header.

There's also "CORS and RFC1918"[1], which IMO would be a great way to stop apps from unintentionally exposing themselves to the open web.

[1]: https://wicg.github.io/cors-rfc1918/#headers

I tried this and Chrome complains about mixed mode and forces you to allow this behaviour and then to reload the page before you can get it working. If that's acceptable, then sure, but for actual use it's not really any good.

Did you connect to ws://localhost:<port>/?

As mentioned in the bug above, this approach is currently recommended by Chrome and in use by a number of large applications/sites.

It's completely transparent and is being used in production today.

I'm desperate for this. The hardware product I work on can be controlled by a mobile app. It was a very deliberate decision to not make the hardware product and mobile app both have to talk to a remote server acting as a proxy between the two. But that leaves me using plain http between the two.

We ended up using the WebRTC data channel to set up communication between our hardware product and mobile app.

There’s still a necessity for a signalling server in between to set up the communication, and a STUN/TURN server to proxy where it’s not possible to set up direct channels. But the whole thing is super low latency and uses DTLS, so it’s a nice alternative for many use cases!

> We ended up using the WebRTC data channel ...

That is an interesting approach. Unfortunately we also have to support browsers so it doesn't look like we could use it. (You have to type in http://something to get the page that does the webrtc as far as I can tell.)

WebRTC can be used a server fashion. We opened a library that does just that: https://blog.rainway.io/real-time-communication-for-everyone...

Unfortunately not applicable. The problem is a user with a regular desktop browser open and has the ip address of the device (on the same subnet). They have to type something into the browser address bar.

As far as I can tell, there is no way they could type something like webrtc://1.2.3.4 and would have to type something beginning with http or https. It can't be the latter because of signing issues, so we are still stuck with http.

More than happy to offer my thoughts if you want to reach out: [email protected]

Couldn't you use it to coordinate NAT punchthrough?

The mobile app (or web browser) are on the same network (subnet) as the hardware device. There is no need for NAT or anything else. Zeroconf is used for discovery.

There is little threat in most home networks, but I still prefer using SSL. If we only had to support the mobile app then we could implement a solution (eg ssh style trust on first use with self signed certificates). However we also have to support regular browsers which constrains us to standard protocols and security.

I'm working on a product that has a similar case - we luckily have the benefit of the hardware having a display and input so that clients need to effectively pair themselves (i.e. you need to physically click an authorized button on the hardware) before they can have full access. We figure that if someone/something has access to the hardware, you're already boned.

We also have a display and also do pairing. You have to press a physical button the device which results in a 4 digit code on the display that has to be entered in the browser or app (somewhat analogous to bluetooth pairing). At the end of the day this results in a cookie being set. But the traffic is still over http.

We built a PKI on top of Lets Encrypt to deliver certificates to all of our users for Rainway: https://rainway.io/technology/

Similar to Plex, users run our software on their PC and then our web based client can connect to it from elsewhere.

It’s mainly used as a fallback if WebRTC fails (https://blog.rainway.io/real-time-communication-for-everyone...). If there is interest, happy to do a blog post.

Isn't this exactly what the blog post is saying not to do?

> By introducing a domain name instead of an IP address, you make it possible for an attacker to Man in the Middle (MitM) the DNS lookup and inject a response that points to a different IP address. The attacker can then pretend to be the local app and send fake responses back to the web app, which may compromise your account on the web app side, depending on how it is designed.

Only if you ship the private key with your app. Otherwise the MITM will fail certificate validation.

How would you run a local HTTPS server without the private key?

They get one private key per user, and send it to the client's device.

The private key is generated on the client side, and signed by the certificate. Plex has an intermediate which they control to issue these. It would not pass normal validation processes.

Which "compromises" the key, according to current Certificate Authorities policies. Once again the problem boils down to CAs being the sole "anchors of trust" in the current certificate system.

Then they could have their server tunnel ACME challenges to the device, so the private key never leaves the device, but can still be signed.

Oh, indeed.

Couldn't the web app also verify that the localhost.example.com domain resolves to 127.0.0.1 before attempting a connection?

What prevents you from using letsencrypt? They issue wildcard certificates now. Is there tight limit on number of subdomains?