Hacker News Reader

Comment by Sean-Der | Hacker News Reader

Unfortunately no.

`localhost` is allowed. Could you reverse port forward the service to localhost? That will get around those restrictions.

View on HN

The service/webserver is running on the device, and clients connect via let's say a cell phone to the devices wifi network. The client talks to the webserver via a wifi network from the device. I don't think there's any way to trick the client into thinking the device is localhost? Maybe some HSTS shenanigans?

Self signed certs would be much easier. Or a CA and certs signed by that; since it’s a controlled environment maybe you can install that CA to the trust store on the viewing devices.

Unfortunately I don't control all of the clients and I'm using self signed certs now. It's just a hassle having to explain to non cs folks how to click past the unsafe prompt which looks to them like an error.

Meanwhile I can hack together a poor man's webrtc by sending raw packets over websockets and playback works just fine. I just lose all the real benefits of webrtc (robustness, udp vs tcp, etc.). It feels like it should be possible to work around "secure context" nonsense since I don't access anything on the clients, they just play back a stream from the devices. But chrome/ff tends to block the ice handshake in http mode.

If you’re serving DNS to the clients too, and you’re able to push updates to these devices regularly enough somehow, you can also use real certs with names under some public DNS zone that you control. (Make it resolve to a public IP on the Internet so you can issue/renew the cert, and a private IP on the private network.)

But yeah, one way or another, you need a secure context for WebRTC to work. That’s in the spec, and browsers follow it.

Perhaps in your context it really is nonsense, but how is the browser to know that your network/physical layer is secure?

What prevents you from using an actual cert from a trusted CA?

Reply on news.ycombinator.com