search

nymtech / nym

Nym provides strong network-level privacy against sophisticated end-to-end attackers, and anonymous transactions using blinded, re-randomizable, decentralized credentials.
https://nymtech.net
1.24k stars 227 forks source link

Autodiscover announced IP #112

Open ststefa opened 4 years ago

ststefa commented 4 years ago

Currently the --host and --announce parameters already allow to run a mixnode in a NAT setup where the local IP is different from the announced IP.

While this is already cool for tech-savvy people it might overwhelm a non-techie. Also the requirement for explicit configuration makes it difficult to (one day) release zero-conf style appliances (nymberries?) that anyone could just plug into their home network to fight mass surveillance. Of course this is just one of many challenges for building such an appliance.

I'd thus vote that a feature which will autodiscover the local and public (i.e. NATed) IPs will be useful.

The default local interface/IP should be rather easy to guess based on routing information.

The public IP could maybe be guessed based on an HTTP style mechanism like http://icanhazip.com (resp. http://v4.icanhazip.com / http://v6.icanhazip.com).

The --host and --announce parameters would still override the guessed defaults.

rachyandco commented 4 years ago

This article give some overview on multiple possible solutions. https://www.cyberciti.biz/faq/how-to-find-my-public-ip-address-from-command-line-on-a-linux/

Please also read the comments. Some methods are a security concern and would leak data (how ironic for Nym). Maybe (some of) the method that provides the feedback on the IP address can be within the Nym network, hosted by Nym or a dnslookup?

ststefa commented 4 years ago

As I understand this suggests that one could either use DNS or HTTP to figure out oneselfs public IP. Here are my 5 cent on the topic:

For the HTTP approach you would have to decide whether to use a public service or to offer the service by yourself. A public service might have the benefit of not disclosing the clients intention. However it has the drawback of theoretically uncertain availability. Hosting a service by yourself would make ones intention pretty visible to an observer. I cannot say whether this "leak of intention" is actually a problem or not. I'd guess that such a leak happens anyway at the time the mixnode advertises itself to the nym directory.

Essentially the same arguments go for the DNS approach.

Looking at my own network setup I'd argue that it's probably more likely for the HTTP approach to not be blocked (I allow any client to do outbound HTTP(S)) than the DNS approach (I deny any client to do outbound DNS and force the use of my local DNS).

Also HTTP(S) would have the benefit of potentially being able to go over a (to be configured) proxy without changing ones firewall setup.