Add more local data - Githubissues

fxbox / registration_server

The registration server to help with foxbox discovery

4 stars 4 forks source link

Add more local data #3

Open fabricedesre opened 8 years ago

fabricedesre commented 8 years ago

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

cr commented 8 years ago

Perhaps every Foxbox should be using a unique and sufficiently strong random ID for registration. This enables a few nice features on the registration server side:

It can more reliably detect external IP address changes, for example due to DSL reconnects.
It can more reliably detect and handle internal IP changes which sometimes occur under common home network DHCP regimes.
It can better handle multi stack environments (IPv4 and IPv6).
It can more easily detect and mitigate malicious behavior. For that the registration should use TLS and the original registration ID must not be returned in pings.

fabricedesre commented 8 years ago

UniqueID == risk of tracking ! I'd like to avoid that if possible.

Being somewhat more aggressive with the re-registration from the client and eviction on the server should mitigate your first 2 points in practice (eg. every 5 minutes). I'm not sure how the last 2 are issues. Which kind of malicious behavior are you thinking about?

michielbdejong commented 8 years ago

We might want to deploy some type of API key or signed client-cert which allows the Box to connect to http://knilxof.org:4242/register?ip=192.168.0.42, so that not just anybody can pretend to be a Box.

arcturus commented 8 years ago

Also, what about registering what's my public name if registered against any proxy solution we could have. (Until the dynamic dns solution is in place)

michielbdejong commented 8 years ago

Also, what about registering what's my public name if registered against any proxy solution we could have. (Until the dynamic dns solution is in place)

Yes, we need that. Right now the Box registers its local IP address. Instead, it should register its public-local DNS host (whether dynamic or not).

I'll prepare a PR for this.

michielbdejong commented 8 years ago

Update: @arcturus mentioned on irc that he wants to keep the interaction-less flow as an option, even after gate 1.

We can however harden this server by requiring the Box to authenticate when registering (with a client cert for instance).

Another hardening option would be white-listing/black-listing CORS origins. For instance, the registration server instance could have an interface where an app developer registers the origin of their web app; if we see abuse, we revoke API access for that origin.