prototype-cjdns-pi
prototype-cjdns-pi copied to clipboard
tomeshnet
Yggdrasil peering security
Yggdrasil allows anyone to peer with you if they have your clearnet IP address and port. A solution to make it more secure (and like CJDNS) is detailed in the FAQ page.
Alternatively, you can limit who can peer with you by modifying the AllowedEncryptionPublicKeys option in your Yggdrasil configuration. When this list is empty, any remote node is allowed to peer with you.
To restrict incoming peerings to certain nodes, you should first ask the operators of those nodes for their EncryptionPublicKey and then add those public keys into your own AllowedEncryptionPublicKeys list. From that point forward, only nodes with those public keys will be allowed to peer with you.
I suggest that this become the default during installation, to better match the expected behavior of those used to CJDNS.
I think there is also value in preserving default behaviour of the source application. Since this is a prototype for people to play with some software, I feel we do not have enough user research to back subjective configurations, and any deviation from application default seem kind of arbitrary.
I would say that since it is an option, it is something we should consider, especially because it is the way CJDNS works. Enabling this would match behaviour that has been used since the beginning of the project. I can ask on the Yggdrasil chat whether this is stable enough or not if that is an issue, but I don't think it is. Do we really want anyone to be able to connect by default? I find this to be a security issue, but if we decide it's not, then maybe CJDNS should have a default password in our stack or something so it's as easy to connect to as Yggdrasil. My point is just that I think it would be nice and intuitive for them both to have similar behaviour. Which behaviour makes sense in our prototype scenario is maybe something to consider.
@darkdrgn2k #238 does help to some degree, but it can't replace the security settings I mentioned above, or the ones in CJDNS.
I dont like the "opt in" model.
But to be fair the local pi model usually is not on the internet so its not a problem anyway?
I dont like the "opt in" model.
Then let's make it the default. I've confirmed with Arceliar that it is a stable feature and will not effect link-local auto-peering.
As said by @benhylau in our chats:
Yes I commented on there yesterday and my position still stands, that I think making custom configurations is (a) arbitrary and (b) counter-intuitive to the user
- Aligning behaviour asks the question, why cjdns behaviour and not ygg behaviour by default, and why this behaviour but not others, there are other things we can make more similar as well, where do we draw the line?
- When someone runs a prototype install script to help them set up a list of applications, they expect it to reflect the default behaviour from reading about that application's README. Changing certain things make users have to dig thru what you changed, which again is arbitrary
If there is a major security issue it could make sense, and we need to document it, but if it is such a big issue why is it default in ygg in the first place. Again, the application designer has better context to inform this decision, as Arceliar explained. I do not feel this is a case where because we are combining this with other applications that makes the risk higher, so I don't see a reason to deviate from default config.
My final stance I think, is that personally I don't like the difference between CJDNS and Yggdrasil in our stack in this regard, but I'm fine with leaving it as it is, and see the value of not altering defaults. It would be nice to see this documented somewhere in our repo so as not to surprise users of CJDNS.
Latest Yggdrasil no longer opens peering port by default needs to be turned on.