Zerotierone: Key before joining host

[learnsia]

I would like to see a feature where the initial join for a node has a key.

That would help prevent someone from either accidentally or using a bot to join dozens of nodes to your network. I have mistyped the Network ID a few times and just received the "OK" message. I did leave the network, but someone could write a bot to flood a Network with bogus hosts.

zerotier-cli join NETWORK_ID -k 02efbca788ffe

That key would be hidden in the web interface, but a little eyeball icon to view it when needed. Again, that is just for the initial join to a network.

[unquietwiki]

@learnsia when you say saving the first key in the web interface, you mean ZT Central? Are you thinking something like a password for authorizing just the first node, or additional nodes?

@adamierymenko @laduke Is this feasible from your perspectives?

[laduke]

It's not an uncommon request. There may be a similar issue in here somewhere. From what I understand, it'd be a post 2.0 thing.

[learnsia]

Michael,

I mean the "key" would be available via the web interface on ZT Central so
it is not forgotten. Also, the initial join by every node would require
it.

Here's another option:

In the ZT Central interface, if someone uses the Private option, there
could be an option that requires manually adding Node IDs. This option
seems feasible with the current version. Since the node that is joining
sends its Node ID to the respective Network, if it is not in the
pre-populated list of allowed nodes, then deny the request to join. The
feature to manually add is already there so it would require checking the
incoming Node ID and check the pre-populated list and if it is not in the
list, then deny the join request. Again that would be an option to
require manual addition of nodes.

On Mon, Aug 17, 2020 at 1:44 PM Travis LaDuke [e-mail]
wrote:

It's not an uncommon request. There may be a similar issue in here
somewhere. From what I understand, it'd be a post 2.0 thing.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/zerotier/ZeroTierOne/issues/1242#issuecomment-675019618,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACROLZ7VF2HKEJNAML37OLSBFT6XANCNFSM4P7BZRGA
.

[unquietwiki]

@learnsia Thank you for clarifying. Per what @laduke said, it's something we can look at after 2.0 is up and running.

[glimberg]

The behavior of a private network is already to deny access by default. A node trying to join a network will request configuration for a while, and then the network status on the node will change from REQUESTING CONFIGURATION to ACCESS DENIED. Without user intervention on the network page, the default state is always unauthorized on a private network. As such, they will show in the member list as unauthorized. You can always select to view only authorized members in the member list in the https://my.zerotier.com interface. We've also never had an instance like you've described of someone attempting to flood a network with joins. Additionally, a typo in the network ID is much more likely to try to join a network that doesn't exist in the first place than to accidentally try joining someone else's network. A network controller can currently host up to 16,777,215 unique networks and we have plans to make that even larger in the future.

I'm not sure how feasible pre-populating a list of nodes allowed to join would be. You can always do that yourself by either POST-ing the node IDs to the API with {"config": { "authorized": true} }, or adding them to the network via the UI beforehand. That way the node is pre-authed when it's joined. Outside of that it will take a lot of re-engineering of the controllers to support some sort of pre-shared list.

As for some sort of key/password provided on network join. That's something that we've thought about, but haven't found a good design for yet. Just a straight password/key opens networks up to brute force attacks, and is IMO less secure than the current method of authorizing members via the web UI or API token. Plus your added feature request "That key would be hidden in the web interface, but a little eyeball icon to view it when needed." That's a big no-no. That means the key is stored in plain text in the database on our end. In the unlikely event that our database somehow got compromised with that feature, your network is compromised, too. There's a reason we store user passwords and API tokens encrypted in the database. If the feature does get out the door one of these days, it'd likely be in the form of cryptographic signatures of identities to auto authorize if anything. But again, that's a ways down the road at the very least.

[learnsia]

Thanks for the feedback.

The key that I was referring to could also be encrypted and protected with
my login password to avoid the big no-no and disclosure if the DB is
compromised, and stored in an encrypted session variable while I am logged
into the console.

Anyway, I've switched to using wireguard to get around the double NAT
issue, due to the setup in our org and sudden change in Zerotier node
limits.

I still suggest people use Zerotier due to its ease of setup, portability,
and ease of setup and configuration.

-duane

"Yesterday I was clever, so I wanted to change the world. Today I am wise,
so I am changing myself." -Rumi

On Mon, Sep 28, 2020, 10:22 PM Grant Limberg [e-mail]
wrote:

The behavior of a private network is already to deny access by default. A
node trying to join a network will request configuration for a while, and
then the network status on the node will change from REQUESTING
CONFIGURATION to ACCESS DENIED. Without user intervention on the network
page, the default state is always unauthorized on a private network. As
such, they will show in the member list as unauthorized. You can always
select to view only authorized members in the member list in the
https://my.zerotier.com interface. We've also never had an instance like
you've described of someone attempting to flood a network with joins.
Additionally, a typo in the network ID is much more likely to try to join a
network that doesn't exist in the first place than to accidentally try
joining someone else's network.

I'm not sure how feasible pre-populating a list of nodes allowed to join
would be. You can always do that yourself by either POST-ing the node IDs
to the API with {"config": { "authorized": true} }, or adding them to the
network via the UI beforehand. That way the node is pre-authed when it's
joined. Outside of that it will take a lot of re-engineering of the
controllers to support some sort of pre-shared list.

As for some sort of key/password provided on network join. That's
something that we've thought about, but haven't found a good design for
yet. Just a straight password/key opens networks up to brute force attacks,
and is IMO less secure than the current method of authorizing members via
the web UI or API token. Plus your added feature request "That key would be
hidden in the web interface, but a little eyeball icon to view it when
needed." That's a big no-no. That means the key is stored in plain text in
the database on our end. In the unlikely event that our database somehow
got compromised with that feature, your network is compromised, too.
There's a reason we store user passwords and API tokens encrypted in the
database. If the feature does get out the door one of these days, it'd
likely be in the form of cryptographic signatures of identities to auto
authorize if anything. But again, that's a ways down the road at the very
least.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/zerotier/ZeroTierOne/issues/1242#issuecomment-700386521,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACROLZ6SHVK44DPRR2NBDDSIFAGFANCNFSM4P7BZRGA
.