mirror of
https://github.com/monero-project/monero.git
synced 2024-11-18 00:37:43 +00:00
973403bc9f
- Support for ".onion" in --add-exclusive-node and --add-peer
- Add --anonymizing-proxy for outbound Tor connections
- Add --anonymous-inbounds for inbound Tor connections
- Support for sharing ".onion" addresses over Tor connections
- Support for broadcasting transactions received over RPC exclusively
over Tor (else broadcast over public IP when Tor not enabled).
179 lines
7.5 KiB
Markdown
179 lines
7.5 KiB
Markdown
# Anonymity Networks with Monero
|
|
|
|
Currently only Tor has been integrated into Monero. Providing support for
|
|
Kovri/I2P should be minimal, but has not yet been attempted. The usage of
|
|
these networks is still considered experimental - there are a few pessimistic
|
|
cases where privacy is leaked. The design is intended to maximize privacy of
|
|
the source of a transaction by broadcasting it over an anonymity network, while
|
|
relying on IPv4 for the remainder of messages to make surrounding node attacks
|
|
(via sybil) more difficult.
|
|
|
|
|
|
## Behavior
|
|
|
|
If _any_ anonymity network is enabled, transactions being broadcast that lack
|
|
a valid "context" (i.e. the transaction did not come from a p2p connection),
|
|
will only be sent to peers on anonymity networks. If an anonymity network is
|
|
enabled but no peers over an anonymity network are available, an error is
|
|
logged and the transaction is kept for future broadcasting over an anonymity
|
|
network. The transaction will not be broadcast unless an anonymity connection
|
|
is made or until `monerod` is shutdown and restarted with only public
|
|
connections enabled.
|
|
|
|
|
|
## P2P Commands
|
|
|
|
Only handshakes, peer timed syncs, and transaction broadcast messages are
|
|
supported over anonymity networks. If one `--add-exclusive-node` onion address
|
|
is specified, then no syncing will take place and only transaction broadcasting
|
|
can occur. It is therefore recommended that `--add-exclusive-node` be combined
|
|
with additional exclusive IPv4 address(es).
|
|
|
|
|
|
## Usage
|
|
|
|
Anonymity networks have no seed nodes (the feature is still considered
|
|
experimental), so a user must specify an address. If configured properly,
|
|
additional peers can be found through typical p2p peerlist sharing.
|
|
|
|
### Outbound Connections
|
|
|
|
Connecting to an anonymous address requires the command line option
|
|
`--proxy` which tells `monerod` the ip/port of a socks proxy provided by a
|
|
separate process. On most systems the configuration will look like:
|
|
|
|
> `--proxy tor,127.0.0.1:9050,10`
|
|
> `--proxy i2p,127.0.0.1:9000`
|
|
|
|
which tells `monerod` that ".onion" p2p addresses can be forwarded to a socks
|
|
proxy at IP 127.0.0.1 port 9050 with a max of 10 outgoing connections and
|
|
".i2p" p2p addresses can be forwarded to a socks proxy at IP 127.0.0.1 port 9000
|
|
with the default max outgoing connections. Since there are no seed nodes for
|
|
anonymity connections, peers must be manually specified:
|
|
|
|
> `--add-exclusive-node rveahdfho7wo4b2m.onion:28083`
|
|
> `--add-peer rveahdfho7wo4b2m.onion:28083`
|
|
|
|
Either option can be listed multiple times, and can specify any mix of Tor,
|
|
I2P, and IPv4 addresses. Using `--add-exclusive-node` will prevent the usage of
|
|
seed nodes on ALL networks, which will typically be undesireable.
|
|
|
|
### Inbound Connections
|
|
|
|
Receiving anonymity connections is done through the option
|
|
`--anonymous-inbound`. This option tells `monerod` the inbound address, network
|
|
type, and max connections:
|
|
|
|
> `--anonymous-inbound rveahdfho7wo4b2m.onion:28083,127.0.0.28083,25`
|
|
> `--anonymous-inbound foobar.i2p:5000,127.0.0.1:30000`
|
|
|
|
which tells `monerod` that a max of 25 inbound Tor connections are being
|
|
received at address "rveahdfho7wo4b2m.onion:28083" and forwarded to `monerod`
|
|
localhost port 28083, and a default max I2P connections are being received at
|
|
address "foobar.i2p:5000" and forwarded to `monerod` localhost port 30000.
|
|
These addresses will be shared with outgoing peers, over the same network type,
|
|
otherwise the peer will not be notified of the peer address by the proxy.
|
|
|
|
### Network Types
|
|
|
|
#### Tor
|
|
|
|
Options `--add-exclusive-node` and `--add-peer` recognize ".onion" addresses,
|
|
and will properly forward those addresses to the proxy provided with
|
|
`--proxy tor,...`.
|
|
|
|
Option `--anonymous-inbound` also recognizes ".onion" addresses, and will
|
|
automatically be sent out to outgoing Tor connections so the peer can
|
|
distribute the address to its other peers.
|
|
|
|
##### Configuration
|
|
|
|
Tor must be configured for hidden services. An example configuration ("torrc")
|
|
might look like:
|
|
|
|
> HiddenServiceDir /var/lib/tor/data/monero
|
|
> HiddenServicePort 28083 127.0.0.1:28083
|
|
|
|
This will store key information in `/var/lib/tor/data/monero` and will forward
|
|
"Tor port" 28083 to port 28083 of ip 127.0.0.1. The file
|
|
`/usr/lib/tor/data/monero/hostname` will contain the ".onion" address for use
|
|
with `--anonymous-inbound`.
|
|
|
|
#### Kovri/I2P
|
|
|
|
Support for this network has not been implemented. Using ".i2p" addresses or
|
|
specifying "i2p" will currently generate an error.
|
|
|
|
|
|
## Privacy Limitations
|
|
|
|
There are currently some techniques that could be used to _possibly_ identify
|
|
the machine that broadcast a transaction over an anonymity network.
|
|
|
|
### Timestamps
|
|
|
|
The peer timed sync command sends the current time in the message. This value
|
|
can be used to link an onion address to an IPv4/IPv6 address. If a peer first
|
|
sees a transaction over Tor, it could _assume_ (possibly incorrectly) that the
|
|
transaction originated from the peer. If both the Tor connection and an
|
|
IPv4/IPv6 connection have timestamps that are approximately close in value they
|
|
could be used to link the two connections. This is less likely to happen if the
|
|
system clock is fairly accurate - many peers on the Monero network should have
|
|
similar timestamps.
|
|
|
|
#### Mitigation
|
|
|
|
Keep the system clock accurate so that fingerprinting is more difficult. In
|
|
the future a random offset might be applied to anonymity networks so that if
|
|
the system clock is noticeably off (and therefore more fingerprintable),
|
|
linking the public IPv4/IPv6 connections with the anonymity networks will be
|
|
more difficult.
|
|
|
|
### Bandwidth Usage
|
|
|
|
An ISP can passively monitor `monerod` connections from a node and observe when
|
|
a transaction is sent over a Tor/Kovri connection via timing analysis + size of
|
|
data sent during that timeframe. Kovri should provide better protection against
|
|
this attack - its connections are not circuit based. However, if a node is
|
|
only using Kovri for broadcasting Monero transactions, the total aggregate of
|
|
Kovri/I2P data would also leak information.
|
|
|
|
#### Mitigation
|
|
|
|
There is no current mitigation for the user right now. This attack is fairly
|
|
sophisticated, and likely requires support from the internet host of a Monero
|
|
user.
|
|
|
|
In the near future, "whitening" the amount of data sent over anonymity network
|
|
connections will be performed. An attempt will be made to make a transaction
|
|
broadcast indistinguishable from a peer timed sync command.
|
|
|
|
### Intermittent Monero Syncing
|
|
|
|
If a user only runs `monerod` to send a transaction then quit, this can also
|
|
be used by an ISP to link a user to a transaction.
|
|
|
|
#### Mitigation
|
|
|
|
Run `monerod` as often as possible to conceal when transactions are being sent.
|
|
Future versions will also have peers that first receive a transaction over an
|
|
anonymity network delay the broadcast to public peers by a randomized amount.
|
|
This will not completetely mitigate a user who syncs up sends then quits, in
|
|
part because this rule is not enforceable, so this mitigation strategy is
|
|
simply a best effort attempt.
|
|
|
|
### Active Bandwidth Shaping
|
|
|
|
An attacker could attempt to bandwidth shape traffic in an attempt to determine
|
|
the source of a Tor/Kovri/I2P connection. There isn't great mitigation against
|
|
this, but Kovri/I2P should provide better protection against this attack since
|
|
the connections are not circuit based.
|
|
|
|
#### Mitigation
|
|
|
|
The best mitigiation is to use Kovri/I2P instead of Tor. However, Kovri/I2P
|
|
has a smaller set of users (less cover traffic) and academic reviews, so there
|
|
is a tradeoff in potential isses. Also, anyone attempting this strategy really
|
|
wants to uncover a user, it seems unlikely that this would be performed against
|
|
every Tor/Kovri/I2P user.
|
|
|