5 ms·

The Plex approach to this kind of problem is pretty interesting: https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/ https://blog.filippo.io/how-

The Plex approach to this kind of problem is pretty interesting: https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/ https://blog.filippo.io/how-plex-is-doing-https-for-all-its-... 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.

rogerbinns 8y ago
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.
- pstuart 8y ago
  Couldn't you use it to coordinate NAT punchthrough?
  - rogerbinns 8y ago
    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.
    - mdtusz 8y ago
      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.
      - rogerbinns 8y ago
        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.
- matthewmacleod 8y ago
  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!
  - rogerbinns 8y ago
    > 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 http://something to get the page that does the webrtc as far as I can tell.)
    - andrewmd5 8y ago
      WebRTC can be used a server fashion. We opened a library that does just that: https://blog.rainway.io/real-time-communication-for-everyone-6f27e02c2f14 https://blog.rainway.io/real-time-communication-for-everyone...
      - rogerbinns 8y ago
        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.
        andrewmd5 8y ago
        More than happy to offer my thoughts if you want to reach out: andrew@rainway.io
andrewmd5 8y ago
We built a PKI on top of Lets Encrypt to deliver certificates to all of our users for Rainway: https://rainway.io/technology/ 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-6f27e02c2f14 https://blog.rainway.io/real-time-communication-for-everyone...). If there is interest, happy to do a blog post.
- krehl 8y ago
randomfool 8y ago
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.
- Ajedi32 8y ago
  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 https://wicg.github.io/cors-rfc1918/#headers
- chillydawg 8y ago
  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.
  - randomfool 8y ago
    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.
progval 8y ago
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.
- hamandcheese 8y ago
  Only if you ship the private key with your app. Otherwise the MITM will fail certificate validation.
  - aethr 8y ago
    How would you run a local HTTPS server without the private key?
    - progval 8y ago
      They get one private key per user, and send it to the client's device.
      - ajnin 8y ago
        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.
        progval 8y ago
        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.
      - BillinghamJ 8y ago
        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.
vbezhenar 8y ago
What prevents you from using letsencrypt? They issue wildcard certificates now. Is there tight limit on number of subdomains?

rogerbinns 8y ago

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.

pstuart 8y ago
Couldn't you use it to coordinate NAT punchthrough?
- rogerbinns 8y ago
  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.
  - mdtusz 8y ago
    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.
    - rogerbinns 8y ago
      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.
matthewmacleod 8y ago
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!
- rogerbinns 8y ago
  > 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 http://something to get the page that does the webrtc as far as I can tell.)
  - andrewmd5 8y ago
    WebRTC can be used a server fashion. We opened a library that does just that: https://blog.rainway.io/real-time-communication-for-everyone-6f27e02c2f14 https://blog.rainway.io/real-time-communication-for-everyone...
    - rogerbinns 8y ago
      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.
      - andrewmd5 8y ago
        More than happy to offer my thoughts if you want to reach out: andrew@rainway.io

andrewmd5 8y ago

We built a PKI on top of Lets Encrypt to deliver certificates to all of our users for Rainway: https://rainway.io/technology/ 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-6f27e02c2f14 https://blog.rainway.io/real-time-communication-for-everyone...). If there is interest, happy to do a blog post.

krehl 8y ago

randomfool 8y ago

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.

Ajedi32 8y ago
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 https://wicg.github.io/cors-rfc1918/#headers
chillydawg 8y ago
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.
- randomfool 8y ago
  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.

progval 8y ago

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.

hamandcheese 8y ago
Only if you ship the private key with your app. Otherwise the MITM will fail certificate validation.
- aethr 8y ago
  How would you run a local HTTPS server without the private key?
  - progval 8y ago
    They get one private key per user, and send it to the client's device.
    - ajnin 8y ago
      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.
      - progval 8y ago
        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.
    - BillinghamJ 8y ago
      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.

vbezhenar 8y ago

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