daemon: add command line arg to set socks proxy

[tobtoht]

Patch originally provided by wfaressuissia[m] in #monero-dev, with minor changes.

Tails does not transparently torify traffic, as such torsocks must be used in absence of application-level configuration. This introduces various issues, such as long timeouts (See: #6708 (comment)) and problems closing monerod because torsocks likes to eat sigints. This patch eliminates the need for torsocks by introducing a command line argument for setting the socks proxy. This will also allow the GUI to spawn monerod without using torsocks to fix simple and bootstrap mode on Tails.

[xiphon]

i think the option should prevent monerod from making any clearnet connections.

For example, DNS queries will still go over clearnet, leaking the original IP. Same for bootstrap daemon connections.

This will also allow the GUI to spawn monerod without using torsocks to fix simple and bootstrap mode on Tails.

Not yet. The current implementation won't use specified proxy for bootstrap daemon connections.

[selsta]

@xiphon this is updated now

[selsta]

@vtnerd Any objections here? Otherwise I will add it to the merge queue.

[cirocosta]

nice!

for anyone wanting to try the changes, an easy way of doing so on linux is to leverage iptable's logging matching on traffic generated by monerod

e.g., one can do that by making monerod run under a group that's only going to run monerod and nothing else that touches the networking stack, and then using the owner matching iptables mod, log the traffic

1. create monero group and add your user to it

# addgroup --system monero
# adduser `whoami` monero 

2. add the iptables rules that will log any outgoing traffic from processes in that group

# iptables   -A OUTPUT -m owner --gid-owner monero -j LOG --log-prefix 'monero: '

3. clear the kernel messages ring buffer (iptables being a kernel module, will output its logs there)

# dmesg --clear

4. switch the current group to monero, then run monerod under that group with the flags you want to test

# newgrp monero
$ monerod \
        --data-dir=/home/ubuntu/monerod-data \
        --enforce-dns-checkpointing \
        --no-igd \
        --non-interactive \
        --p2p-bind-port=58080 \
        --rpc-bind-port=58081 \
        --rpc-restricted-bind-port=58089 \
        --tx-proxy tor,127.0.0.1:9050,10 \
        --proxy 127.0.0.1:9050

5. look for the logs under the ring buffer

dmesg

without --proxy-allow-dns-leaks we can see that there are only connections to the proxy (127.0.0.1:9050), and with it set, then we see connections to 127.0.0.1:53 (local dns resolver) and subsequently connections to clearnet ips as well as the proxy

---

before we forget, should docs/ANNONIMITY_NETWORKS.md be updated to mention the new flags? Outbound Connections section, more specifically.

[vtnerd]

Can you think of anywhere to put a comment about this mode? There's no way to prevent future mistakes with socket connections in the daemon (afaik), but having this written somewhere at the top of node_node.inl perhaps? I guess the reviewers will just have to remain vigilante really.

I will do the dull work of updating docs/ANONYMITY_NETWORKS.md unless you want to.

[vtnerd]

Should it be an error if someone sets the proxy_allow_dns_leaks = false flag without setting the other flag? It works as-is, but the error reporting helps the user without pointless configurations.

[tobtoht]

Added a warning message above (I assume only showing a message is sufficient, since the behavior is unaffected). Let me know if there is a better place to put this, though.

[xanoni]

Great PR, I'm sure many people will appreciate it. Assume this could also be used to more easily hide monerod behind a VPN or SSH tunnel, for the less paranoid who don't want to sacrifice performance.

Q1)
Just to confirm, would this send ALL traffic over Tor, including high volume block downloads?

Q2)
Could someone briefly summarize what the trade-offs are, if one has the choice between using monerod over Tor with this new switch (Option A) vs. using monerod without switch & without torsocks, but with --tx-proxy=tor,xxx (Option B)?

E.g.:

• (A) ensures that the ISP and other people along the network can't detect the presence of a monerod
• (B) is more performant and faster, and also puts less stress on the Tor network (less of a problem if a VPN is used)
• (A) increases the likelihood of Sybil attacks on nodes
• ...

Q3)
How come the opinion on this changed? When I read the docs not too long ago, it seemed that sending everything over Tor was not desirable.

[vtnerd]

Just to confirm, would this send ALL traffic over Tor, including high volume block downloads?

Everything is sent over the socks proxy, so yes.

Could someone briefly summarize what the trade-offs are, if one has the choice between using monerod over Tor with this new switch (Option A) vs. using monerod without switch & without torsocks, but with --tx-proxy=tor,xxx (Option B)?

The option in this PR uses exit nodes, whereas the previous option uses hidden services. Your examples are spot-on for the tradeoffs, and I'm not aware of any other major ones.

The other interesting part of this mode is using a VPN/VPS proxy. You can conceal your home IP address but still have the blockchain verified on a machine you control. This pushes an eclipse attack to the VPN/VPS network from your local ISP, but whether this is a better or worse will depend heavily on the local ISP.

How come the opinion on this changed? When I read the docs not too long ago, it seemed that sending everything over Tor was not desirable.

The opinion hasn't changed, defending against eclipse attacks are difficult. Attackers can get exit nodes banned, forcing connections through a handful of nodes. Or with hidden services, many sybils can be created cheaply, and there is nothing analogous to IPv4 subnet zones to "spread" connections.

Unfortunately, how much this matter is hard to quantify. Some people find the tradeoffs worth it. Its unlikely to be the default setup for the GUI, but maybe this will change (i.e. perhaps the sybil case with hidden services is much harder in practice).

[xanoni]

The option in this PR uses exit nodes, whereas the previous option uses hidden services.

Let's make sure I understand this.

Scenario A:
Send all traffic over Tor, don't use hidden service.

$ monerod \
[...]
    --proxy=127.0.0.1:9050 \
    --tx-proxy tor,127.0.0.1:9050,10 \
    --tx-proxy i2p,127.0.0.1:4447,10 \
    --p2p-ignore-ipv4=0 \
    --no-igd \
    --p2p-bind-ip=0.0.0.0 \
    --p2p-bind-port=58080 \
    --rpc-bind-ip=0.0.0.0 \
    --rpc-bind-port=58081 \
    --rpc-restricted-bind-port=58089 \
[...]

Questions:

1. Is it correct that there is no way to achieve inbound connections here, given that without an .onion other nodes/wallets have no way of figuring out how/where to reach us?
2. ... or would the --(p2p|rpc)-bind-ip=0.0.0.0 arguments create leaks by ignoring the proxy?
3. What effect does --tx-proxy=tor have here? I would assume you could leave it out? Then where would you specify the .onion connection count (",10")?
4. Similarly, I assume the I2P tx-proxy statement would fully bypass --proxy?

Scenario B:
Send all traffic over Tor, use hidden service.

## only showing the (changed|new) parameters vs. (A)
##########################################################

$ monerod \
[...]
    --anonymous-inbound=<OnionAddr>.onion:313373,127.0.0.1:313373,20
    --anonymous-inbound=<I2PAddr>.b32i2p:313374,127.0.0.1:313374,20
[...]

Question:
5. Would inbound connections via .i2p / .onion now be possible, and would they fully bypass the --proxy setting?

Scenario C:
As in B, but also disable external IPv4 / IPv6 listening.

## only showing the (changed|new) parameters vs. (A)
##########################################################

$ monerod \
[...]
    --anonymous-inbound=<OnionAddr>.onion:313373,127.0.0.1:313373,20
    --anonymous-inbound=<I2PAddr>.b32i2p:313374,127.0.0.1:313374,20
    --p2p-bind-ip=127.0.0.1 \
    --rpc-bind-ip=127.0.0.1 \
    --p2p-ignore-ipv4=1
    --p2p-use-ipv6=0 \
    --rpc-ignore-ipv4=1
    --rpc-use-ipv6=0 \
[...]

Question:
6. In practice, is this the same as (B), given we can't have inbound clearnet connections anyway?

Thank you!

[xanoni]

Or with hidden services, many sybils can be created cheaply, and there is nothing analogous to IPv4 subnet zones to "spread" connections.

Defense 1:
Can significant Sybil resistance be gained by listening on both I2P and on Tor? Or is there a realistic way for an attacker to link the I2P and Tor addresses? E.g., does monerod broadcast/exhibit some type of unique fingerprint / identifier / key that would allow an attacker to map the addresses?

Defense 2:
Besides, would it be possible to configure multiple .onion and .b32.i2p addresses for the same node, to then listen on all of them in parallel (I know that Tor and I2P are not the constraint, but maybe monerod would get confused)? If yes, would there be a way for an attacker to find all your .onion's or all your .b32.i2p's to then Sybil each of them?

[vtnerd]

Scenario (A) will send transactions over hidden services but all other traffic (IPv4+6) over VPN/exit node. The bind-ip arguments could be considered a leak if someone could port-scan that external IP address remotely. Anonymous inbound is helpful for routing transactions from other nodes. Inbound IPv4+6 connections only work if the VPN can listen+forward to the external IP, which isn't going to be possible with Tor. In most situations, this will have to be a small VPS running SSH twice - one for outbound socks connections and one for forwarded inbound connections.

Scenario (B) does nothing but allow incoming transactions over those networks. You aren't allowing inbound IPv4+6 connections. Blocks can only be fetched/synced over IPv4+6.

Scenario (C) may be better for privacy if there is no firewall/nat between the host and internet. Otherwise port scanning will reveal an open port.

---

Can significant Sybil resistance be gained by listening on both I2P and on Tor? Or is there a realistic way for an attacker to link the I2P and Tor addresses? E.g., does monerod broadcast/exhibit some type of unique fingerprint / identifier / key that would allow an attacker to map the addresses?

A node is not supposed to be linkable across "zones", so this should not be the case. So syncing top-of-chain over Tor+I2P might mitigate the sybil/eclipse attack. In the worse case an attacker just floods both networks with hidden services though, as aliases are cheaper to create than IPv4 (although IPv6 has some massive subnets). The worse such an attacker can do at the moment is prevent transactions over Tor/I2P from being broadcast. In the block-syncing scenario the attacker controls the perceived "top block".

---

Besides, would it be possible to configure multiple .onion and .b32.i2p addresses for the same node, to then listen on all of them in parallel (I know that Tor and I2P are not the constraint, but maybe monerod would get confused)? If yes, would there be a way for an attacker to find all your .onion's or all your .b32.i2p's to then Sybil each of them?

It's not possible to listen in "parallel" without significant changes. Only one instance of Tor or I2P is allowed internally, and I don't know how "parallel" instances would work with command-line specified nodes. Currently everything with .i2p gets routed to the I2P instance, etc.

I'm also not certain on the amount of work to change this (ignoring the command line funkiness). The mode would be helpful in cases where spamming the entire network with aliases is unfeasible, unworkable, etc.

[xanoni]

The bind-ip arguments could be considered a leak if someone could port-scan that external IP address remotely.

Thank you for explaining the scenarios. The interaction of these arguments can get very confusing. Maybe worth adding some warning messages if people do seemingly dumb things.

In scenario A, is --tx-proxy required to communicate with Tor hidden services, or would the --proxy already handle that?

I'm also not certain on the amount of work to change this (ignoring the command line funkiness). The mode would be helpful in cases where spamming the entire network with aliases is unfeasible, unworkable, etc.

Yeah I understand, I was just trying to understand Monero better and what risks nodes are exposed to. My takeaway is that running a primarily Tor+I2P node with a small number of IPv4 peers primarily for block downloads (with or without --proxy) should be relatively safe.

PS: This is out of scope and I think I mentioned it in other tickets already, but I believe several options should be renamed to make clear that they only refer to a certain network (e.g., in-peers and out-peers only affect clearnet ... for others I still have no idea if they also affect Tor/I2P, such as for limit-rate-(up|down) and hide-my-port).

[vtnerd]

In scenario A, is --tx-proxy required to communicate with Tor hidden services, or would the --proxy already handle that?

--tx-proxy is needed to communicate with hidden services, otherwise transactions are sent through Tor exit nodes.

PS: This is out of scope and I think I mentioned it in other tickets already, but I believe several options should be renamed to make clear that they only refer to a certain network (e.g., in-peers and out-peers only affect clearnet ... for others I still have no idea if they also affect Tor/I2P, such as for limit-rate-(up|down) and hide-my-port).

--in-peers and --out-peers apply to all zones independently. The poster from the other issue seemed to think that this was a global limit, but that seemed like a bad idea (as it could prevent connections in zones). It is not possible to set per-zone limits.

--limit-rate-(up|down) should be universally applied to all TCP connections (including HTTP server, and p2p connections from every zone). The limit is per-connection.

[xanoni]

EDIT: Realize this is somewhat off-topic, sorry don't mean to derail the discussion :)

--in-peers and --out-peers apply to all zones independently. The poster from the other issue seemed to think that this was a global limit, but that seemed like a bad idea (as it could prevent connections in zones). It is not possible to set per-zone limits.

Not sure if that's what you're saying, but I found this setting to only affect my clearnet connections. E.g., if I set out_peers 0 in the RPC console then all my IP connections disappear, however Tor and I2P connections are unaffected. This is the way it's supposed to be, yes? So it should really be called ip_out_peers and ip_in_peers?

--limit-rate-(up|down) should be universally applied to all TCP connections (including HTTP server, and p2p connections from every zone). The limit is per-connection.

When you say per connection, do you mean per peer? I thought it was a global cap across all connections (e.g., peer connections), I was just not sure if it also affected Tor/I2P connections. I didn't digest all of the code, but I thought I had seen that there was a global cap across all connections (or at least IP connections, not sure where Tor/I2P come in).

monero/contrib/epee/src/connection_basic.cpp

Line 237 in dcba757

void connection_basic::sleep_before_packet(size_t packet_size, int phase, int q_len) {

monero/contrib/epee/src/network_throttle-detail.cpp

Line 136 in dcba757

m_target_speed = 16 * 1024; // other defaults are probably defined in the command-line parsing code when this class is used e.g. as main global throttle

monero/contrib/epee/src/network_throttle-detail.cpp

Line 274 in dcba757

const double M = m_target_speed; // max