Updating node location during normal operation

[tcatm]

Yesterday, I've been talking with other freifunkers about Gluon's new features. I've concluded, that not being able to update a nodes' location remotely is a huge problem. This is mainly due to the actual workflow of setting up nodes being different from what we anticipated.

Workflow mismatch

Our anticipated workflow looks something like this:

1. User wants to setup a new node,
2. thinks exactly about where to put it and retrieves WGS84 coordinates for that location,
3. installs firmware,
4. visits configmode,
5. sets location,
6. places at said location,
7. submits public key to community.

However, the more common workflow seems to be:

1. Users wants to setup a new node,
2. installs firmware,
3. visits configmode,
4. submits public key,
5. thinks about where to put it,
6. places node at desired location.

Essentially, the user does not know where the node will be located when entering configmode and forcing her to retrieve it at that point is a burden. This is also a problem when moving a node to a new location.

Proposed solution

We'll add a simple codeword[1] the use can set in configmode. This codeword will allow changing a nodes location on the statuspage. It won't be the root password nor will it allow logging in. It's just a shared secret to authenticate changing longitude and latitude of the node.

It will not allow changing whether the location is shared or not. This will prevent attackers from making a hidden node visible. Should a user desire to change the visibility of her node she must go through configmode again.

It will not allow changing the hostname. I consider changing a nodes hostname potentially harmful if done by an attacker. Again, configmode is required.

It will not allow changing the codeword itself. Thus, an attacker won't be able to lock a node to a location after gaining knowledge of the codeword. Again, configmode enforced.

If no codeword is set, changing the location will not be possible at all. In this case the user will have to visit configmode again in order to update the location. Just as it is now. We should encourage this for "important" nodes.

In my opinion, these three properties will prevent attackers from harming a node badly and thus enabling us to encourage re-use of the codeword for all nodes of a user. An attacker sniffing traffic in the mesh could get much more valuable information than the codeword and, should he desire to mess with the map, inject or manipulate alfred packages directly. Effectively, the codeword-approach will be (maybe just little) more secure than our current wiki approach (which anyone can edit). Still, I do not like sending the codeword in plaintext over the mesh but neither would I want to restrict it to the next-node address (some nodes on roofs might not be reachable through next-node or there may be too many nodes close together so the user can not select the desired node) and I think we should work on solving this issue in later Gluon releases.

Thanks for reading, and thanks to Linus and everyone else I've talked to regarding this issue for their input! Please let me know what you think about this in the comments.

(Did I mention the statuspage would be able to show a map so the user can place her node without knowing about WGS84?)

[1]: like a password but without any security requirements. I'd consider "foo" reasonable.

[jplitza]

Good thing you mentioned that last point in parenthesis, because it convinced me. ;-P

@T-X and me had a huge discussion about putting configuration parts in the Statuspage on IRC and I still am very uncomfortable making the status page read-write and script-based (because, you know, it opens up the possibility for security holes). And I still see the greatest problem in the "codeword": People will blindly enter their usual password there, no matter how big, fat, bold and blinking the warning is not to do so. And the setting of the codeword really should got to the expert mode, I think.

If this gets implemented, maybe it is possible to implement the authentication using HTTP Digest? That way an attacker would have to use MITM instead of plain sniffing.

[sargon]

Yeah, I agree with the workflow problem. And my oppinion is that this is a kiss enougth solution. But still the user needs to figure out the ip address of the node to access the interface. So I propose we should display the possible http ipv6 link in the last page of the router wizard.

But to be concerned, implementing this feature will raise other complains about feature X should be accessible in a similar way. And my opinion is that we shouldn't throw stones in the users way, but also a user installing technology should be aware of it and able to mange it. Especially if it a outdoor roof installation.

Compressed: Implement it, but prepare your arguments.

[tcatm]

HTTP digest

I'd love to use digest based authentication. Unfortunately, uhttpd doesn't support it.

Security Issues / code inject

I"m certain we can handle it well. I haven't heard of any code injection problems with luci so there are probably just a few. We could also run fuzzers to test it.

Codeword / User's password

We could make the input field on configmode a normal field (i.e. no stars) and we definitely should add a short, but concise explaining of the security risks and, again, discourage the user from setting a codeword at all.

Should they still enter their standard password there's not much we can do and they're in trouble anyway.

Link to node

This is indeed an unsolved problem. I could imagine displaying the node's IPv6 address right below codeword input field, like: "Bookmark this [link] to change your node's coordinates once it is running."

Other, similar feature requests

I scoped this very very narrow on purpose because I am aware of those other questions. The greater goal I'd still like to achieve is getting rid of configmode and doing it all during normal operation, remotely across the mesh. However, for this to be secure we've got lots of problems to solve.

Should someone request a similar feature we should either direct him to this issue or a wiki page summing it all up. In either case, we should request him to write a comprehensive issue about the desired feature addressing all security concerns mentioned here and in disccusions he had with other developers. If he succeeds, he might indeed have a valid point.

One-time codeword

I just had another idea, but I would like to not discuss it here, as it might disrupt the workflow too much. We will certainly discuss it after my current solution is either accepted or rejected.

The codeword could be for one-time used. E.g. the first who changes the coordinates (on statuspage) and enter the correct codeword succeeds. After that, it's locked and another codeword has to be set in configmode.

This could be made optional but I fear it might make configmode to complex again (2 checkboxes, 3 input fields to set coordinates).

[jplitza]

Shouldn't HTTP digest be implementable in the script behind uhttpd as well? It's just headers and stuff, after all...

I definitely vote against implementing this for the first gluon release. We rejected making the status page any nicer, which is a relatively unimportant change, so we shouldn't throw this pile of questions in for the first round, I think.

[tcatm]

It's not tagged with a milestone so it's definitely not a showstopper for 2014.1, however if we agree to build it, it might make it into 2014.1.

Yes, you're right. HTTP digest could be possible to implement using just headers.

[neocturne]

Going back to password-based authentication for anything seems like a huge leap backwards to me.

I thought we already had a solution for the map problem? Almost all users are in a WLAN anyways when setting up their node, so we can just load a map from the internet. We just need to provide a good fallback (input fields) for the case when they aren't.

And I don't see a problem with users going having to go back to the config mode once when they install a node somewhere.

[tcatm]

Another option might be making a special configpage accessible using SSH reverse tunneling. This would require the user to supply her SSH public key during configmode.

[ohrensessel]

Why not have a special config page accessible via http://node.ffhh when the node is firstly connected to the freifunk network (via mesh or vpn). if the owner does not visit the config mode, freifunk will not work. maybe with the reset button as some kind of authentication ("press this html button and the reset button within 30s to allow configuring the node").

I'm thinking about that as some kind of plug and play setup with automatic registration of the node on first boot. the automatic connection to the freifunk network (mesh or vpn) would allow to display a map and so on.

[sargon]

I do not think that some hardware interaction is possible if the node is already on some remote location. Also for devices, e.g. ubnt devices, accessing a hardware button is kind of hard.
Instead of some direct http interface we should consider a ssh based configuration interface.
Which could then accessed through a third party https secured interface.
Implementing the ssh configuration interface requires a user with a special configuration shell,
which should not allow any other interactions.

[rubo77]

Any solutions by now? Did someone implement something like this locally already?

[tcatm]

hexa came up with the idea of using a time-based OTP (i.e. RFC 6238) for authentication. I kind of like that approach. For this to work the user would be shown a QR code (+string) for setting up the OTP "Client" (i.e. a smartphone). The user must be able to reset the token (or disable the feature completely).

[viisauksena]

this is far from the convinient idea of easy setting geo with status page (with whatsoever auth mode) .. but if you have ssh connection and you are not frightend by terminals - here are some helpfull minisripts like lat lon alt location geoguess https://github.com/viisauksena/gluon-banner/tree/master/files/usr/bin/ you could add by default to your nodes or your firmware

[rubo77]

What about a big hint

Be sure you wrote down the geo coordinates before you continue

that will be shown only once at the first call of the config mode after a fresh install?

[CodeFetch]

@blocktrron @mweinelt @rotanid Can we close this?

NeoRaider said

And I don't see a problem with users going having to go back to the config mode once when they install a node somewhere.

I think this is true... Going back to config mode is feasible. No overly complicated solution is needed here and this was not implemented in 5 years. So this possibly won't ever be finished...