Unfortunately I haven't seen it being done elsewhere. It'd be nice if LetsEncrypt or similar could provide this for more generic everyday use.
Unfortunately I haven't seen it being done elsewhere. It'd be nice if LetsEncrypt or similar could provide this for more generic everyday use.
And yes, you definitely should whitelist access based on the origin header.
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.
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.
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!
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.)
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.
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.
Deleted comment
> 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.