Connected Devices/Projects/Project Link/Box-Client networking

From MozillaWiki
< Connected Devices‎ | Projects‎ | Project Link
Revision as of 10:50, 11 March 2016 by Michielbdejong (talk | contribs) (Link to login flow mockup)
Jump to navigation Jump to search

Box-Client networking (draft)

Apart from the Box pairing with IoT devices, clients (web pages open on phones and laptops) need to connect with the Box. We call this Client Pairing. There are several ways in which this can work, but for now we're only implementing the first one:

Step 1: The Box generates a self-signed certificate. The fingerprint of that certificate becomes the Box's identifier.

Step 2: The Box is plugged in to an internet router using an ethernet cable. That way it gets access to the internet without the need for selecting an SSID or entering a password.

Step 3: The Box connects to an API (https://github.com/fxbox/dns-server) on knilxof.org to create its public DNS zone under <fingerprint>.knilxof.org, using its self-signed certificate as a client certificate. The API server checks the <fingerprint> from the DNS zone edit request against the fingerprint of the client certificate presented.

Step 4: Now that the Box has a public DNS zone it can control, it can get a LetsEncrypt certificate, using the DNS-01 challenge.

Step 5: The Box sets its main DNS A record to its current *local* IP address which it obtained via DHCP earlier. It will update this A record whenever its local IP address changes.

Step 6: The Box also sets two or more mirror A records to its current local IP address. The idea here being that only one of the records will be cached by caching DNS servers, so switching to the other one at the right time will avoid downtime due to DNS propagation delays. This still has to be worked out in more detail, and tested in practice with the caching DNS servers of real ISPs.

Step 7: The Box starts up a Pagekite client, which connects to a Pagekite frontend, and adds the IP address of the public interface of the Pagekite frontend into its DNS zone.

Step 8: The Box announces all its URLs (local/main, mirrors, tunneled) on the registration server (see https://github.com/fxbox/registration_server).

Step 9: The user opens the app with their browser.

Step 10: The app makes a cross-origin request to the registration server to discover which Boxes are on a network with the same outgoing IP address.

Step 11: If exactly one Box is discovered, the user can click "Connect" and gets redirected to the Box's setup/login page. Once the admin user is created, or the password is entered correctly, the user is redirected back to the app. See also Login Flow (early draft) mockup about this last step.

In the future we plan to make two optional improvements:

  • build-time option to replace the registration server with the scanning of a QR code, or a similar mechanism for the Box and the Client to prove physical proximity to each other.
  • build-time option to use mDNS instead of the public DNS zone, and use URLs of the form https ://<public-key-digest>.<special-tld> instead of browser-trusted CAs, similar to what has been proposed for FlyWeb.