fxbox/registration_server

The registration server to help with foxbox discovery

registration_server's Issues

Add CORS headers?

We want this to be accessible to any web app on any client inside the network, right? Then we need to add a Access-Control-Allow-Origin: * header. It will allow any web page to scan the local network for Boxes that are currently in setup mode, but I think that's the goal, right?

Instead of the box posting a "client_id" discern it from the client certificate used to POST.

Currently a "client" field must be POSTed, ideally we should use a client cert and use the fingerprint of this certificate to identify the client (where the client is a box).

It's not done like this right now as the Iron Framework does not support this easily as it is right now.

Add more local data

The box should also send the port number it's listening on, and maybe the local hostname in addition to the local ip.

Support CORS headers

It seems that the registration server doesn't serve CORS headers.

It should have at least a Access-Control-Allow-Origin header.

Move from persistent Sqlite storage to Redis in memory storage

We don't need the data to be persistent, so we may want to use another storage system like Redis.

Run redis-server from a different Docker container

Instead of running the server and redis in the same container, we should link them and run only the server in the container this project's docker file describes.

Add a chain cert

We can probably use http://ironframework.io/doc/openssl/ssl/struct.SslContext.html#method.set_certificate_chain_file or similar.

Cross-compilation on Mac OS for building Docker container

Instead of building inside the docker container, and then deploying - we should cross compile (or delete intermediate layers in the docker image?) so that the final image is minimal. Maybe switch from debian to the alpine base container.

Add travis configuration

Document reason for needing this

Given that IIUC this registration server needs to be a Mozilla-hosted service, which is not ideal for security, privacy, as well as resilience reasons (the foxbox you own will become useless if we ever decide to discontinue this server). So we should document why we need this, and explain that those reasons outweigh the security/privacy/resilience implications, and which alternative options we discarded.

I think the primary reason is that unlike iOS, Windows, and OSX, Android does not support mDNS, right? Are there other reasons?

And I think one alternative option we discarded was adding mDNS support to Fennec, because this would still leave out users of other browsers on Android (notably the Android stock browser), right?

Remove outdated entries

Right now we just keep the last entry for each (public, local) pair. We should delete those who are older than some threshold.

Whitelist Box client certs and app origins

In order to improve security and privacy, we should:

• remove CORS headers from curl -i -X POST -d'{"local_ip":"foo"}' http://knilxof.org:4242/register
• whitelist origins for /ping end-point (initially only https://app.knilxof.org/; host http://fxbox.github.io/app there).
• whitelist /register clients using signed client certs (we can fake this for the staging build using a signing-cert that's in the foxbox repo)

If we run into difficulties with the signed client certs, a simpler approach would be to add an Authorization header or something similar.

Support for dual stack IPv4 and IPv6 environments

In dual stack environments, Foxbox and client won't necessarily be using the same external IP address for server requests. Foxbox should ensure to register through both IPv4 and IPv6 where available.

It might make sense to return both the internal IPv4 and IPv6 address regardless of which stack was used by the client for the ping. The addresses could be coalesced by a strong random (but reproducible) ID used by the Foxbox for registration.

cloud.desre.org doesn't support IPv6 at this point, so this is certainly a low-priority issue.

Limit amount of data published by Box

Right now, a Box can call:

curl -X POST https://knilxof.org:4243/register -d "{\"local_ip\":\"some...very...long...string\",\"tunnel_url\":\"b\"}"

and we don't limit how long that string is. We should harden this a bit; this is a follow-up to: #11 (comment)

When limiting the length of the string sent in one call, we probably also want to limit the number of calls per second.

We can do this at the same time where we drop the formatting restrictions on the string sent (these restrictions don't really contribute anything apart from complicating our server upgrade path), see #11 (comment)

Problems with `cargo build`

To reproduce:

docker pull schickling/rust
docker run -it schickling/rust /bin/bash
> apt-get update
> apt-get install -y git
> git clone https://github.com/fxbox/registration_server
> cd registration_server
> cargo build

It complains that it can't compile the `formdata` crate.

Add a command line argument

... instead of hardcoding the host:port we listen on.

Document HTTP API