Extending the private ssid with extender nodes

[Juul]

Currently the extender nodes can't extend the private SSID because they don't know the password (pre-shared key). notdhcpserver is not transmitting this information because it has no facility for encryption. notdhcpserver does send other information in the clear, but the worst case scenario if someone intercepts that information is that they can pretend to be an extender node, make an extender node not work or access the private network. Intercepting that information is only possible by having access to the physical ethernet cable going between extender and home node, and if you have access to that then it's game over already: You have access to the private network since the private network is just a VLAN on that cable. I don't think even uneducated users will be surprised to learn that tapping into their physical cable will get people access to their private network.

If we were to send the private wifi password unencrypted, then there are a couple of serious added security problems:

• The attacker would have access to the private network wirelessly and indefinitely after executing the attack, so they could physically for a few seconds to obtain the password and then forever after have access to the private network (or at least until the password changes).
• The owner of the home node may be using the same password for other things outside of our control.

So, if we transmit the password to the extender nodes then we have to transmit the password using a secure channel.

We could send the password using public key crypto, but then anyone pretending to be an extender node would still get it.

The solution is to store the password as a salted hash in the wpa_supplicant.conf file and then simply transmit this hash to the extender nodes. Every time a client device connects, wpa_supplicant simply has to apply the hash to the received password before comparing. This would require two things:

• Patching wpa_supplicant to understand a modern hash like SHA256
• Patching uci to hash the plaintext password from /etc/config/wireless when generating wpa_supplicant.conf

This shouldn't be a problem. The patch to wpa_supplicant will probably be small. It has (or used to have?) an option to store hashed passwords in wpa_supplicant.conf but only using the completely broken and outdated MD4 algorithm (and without a salt), and wpa_supplicant already internally uses SHA256. We might even be able to convince the wpa_supplicant folk to adopt the patch if we explain our use-case.

[eenblam]

@Juul can we close this? Seems less relevant if we're moving away from supporting extender nodes. Similar for #35.

[paidforby]

@eenblam I second closing this. You can easily extend your private network by leaving the default firmware (typically airOS) on an extender node and plugging it into the private port. Not sure about doing that between nodes since it may require some sort of IP scheme to route between the nodes, but that seems outside the scope of this issue.

Also this issue sounds identical to #38 which I imagine can also be closed.