DragonX/dragonx
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 2 Wiki Activity

BIP155 (addrv2)

Browse Source 
Tor v3 + i2p
This commit is contained in:
zanzibar
2023-01-06 15:21:08 +00:00
parent fe9f1ef9e4
commit 512da314a5
108 changed files with 8214 additions and 2173 deletions
Download Patch File Download Diff File Expand all files Collapse all files

161
doc/i2p.md Normal file
View File

@@ -0,0 +1,161 @@
# I2P support in Hush
It is possible to run a Hush or HSC full node as an
[I2P (Invisible Internet Project)](https://en.wikipedia.org/wiki/I2P)
service and connect to such services.
This [glossary](https://geti2p.net/en/about/glossary) may be useful to get
started with I2P terminology.
## Run with an I2P router (proxy)
A running I2P router (proxy) with [SAM](https://geti2p.net/en/docs/api/samv3)
enabled is required. Options include:
- [i2prouter (I2P Router)](https://geti2p.net), the official implementation in
Java
- [i2pd (I2P Daemon)](https://github.com/PurpleI2P/i2pd)
([documentation](https://i2pd.readthedocs.io/en/latest)), a lighter
alternative in C++ (successfully tested with version 2.23 and up; version 2.36
or later recommended)
- [i2p-zero](https://github.com/i2p-zero/i2p-zero)
- [other alternatives](https://en.wikipedia.org/wiki/I2P#Routers)
Note the IP address and port the SAM proxy is listening to; usually, it is
`127.0.0.1:7656`.
Once an I2P router with SAM enabled is up and running, use the following
configuration options:
```
-i2psam=<ip:port>
I2P SAM proxy to reach I2P peers and accept I2P connections (default:
none)
-i2pacceptincoming
If set and -i2psam is also set then incoming I2P connections are
accepted via the SAM proxy. If this is not set but -i2psam is set
then only outgoing connections will be made to the I2P network.
Ignored if -i2psam is not set. Listening for incoming I2P
connections is done through the SAM proxy, not by binding to a
local address and port (default: 1)
```
In a typical situation, this suffices:
```
hushd -i2psam=127.0.0.1:7656
```
The first time hushd connects to the I2P router, if
`-i2pacceptincoming=1`, then it will automatically generate a persistent I2P
address and its corresponding private key. The private key will be saved in a
file named `i2p_private_key` in the Hush data directory. The persistent
I2P address is used for accepting incoming connections and for making outgoing
connections if `-i2pacceptincoming=1`. If `-i2pacceptincoming=0` then only
outbound I2P connections are made and a different transient I2P address is used
for each connection to improve privacy.
## Persistent vs transient I2P addresses
In I2P connections, the connection receiver sees the I2P address of the
connection initiator. This is unlike the Tor network where the recipient does
not know who is connecting to them and can't tell if two connections are from
the same peer or not.
If an I2P node is not accepting incoming connections, then Hush uses
random, one-time, transient I2P addresses for itself for outbound connections
to make it harder to discriminate, fingerprint or analyze it based on its I2P
address.
## Additional configuration options related to I2P
```
-debug=i2p
```
Set the `debug=i2p` config logging option to see additional information in the
debug log about your I2P configuration and connections. Run `hush-cli help
logging` for more information.
```
-onlynet=i2p
```
Make automatic outbound connections only to I2P addresses. Inbound and manual
connections are not affected by this option. It can be specified multiple times
to allow multiple networks, e.g. onlynet=onion, onlynet=i2p.
I2P support was added to Hush in version 3.9.3 and there may be fewer I2P
peers than Tor or IP ones. Therefore, using I2P alone without other networks may
make a node more susceptible to [Sybil
attacks](https://en.bitcoin.it/wiki/Weaknesses#Sybil_attack). You can use
`hush-cli -addrinfo` to see the number of I2P addresses known to your node.
Another consideration with `onlynet=i2p` is that the initial blocks download
phase when syncing up a new node can be very slow. This phase can be sped up by
using other networks, for instance `onlynet=onion`, at the same time.
In general, a node can be run with both onion and I2P hidden services (or
any/all of IPv4/IPv6/onion/I2P/CJDNS), which can provide a potential fallback if
one of the networks has issues.
## I2P-related information
There are several ways to see your I2P address if accepting
incoming I2P connections (`-i2pacceptincoming`):
- in the "Local addresses" output of CLI `-netinfo`
- in the "localaddresses" output of RPC `getnetworkinfo`
- in the debug log (grep for `AddLocal`; the I2P address ends in `.b32.i2p`)
To see which I2P peers your node is connected to, use `hush-cli -netinfo 4`
or the `getpeerinfo` RPC (e.g. `hush-cli getpeerinfo`).
To see which I2P addresses your node knows, use the `getnodeaddresses 0 i2p`
RPC.
## Compatibility
Hush uses the [SAM v3.1](https://geti2p.net/en/docs/api/samv3) protocol
to connect to the I2P network. Any I2P router that supports it can be used.
## Ports in I2P and Hush
Hush uses the [SAM v3.1](https://geti2p.net/en/docs/api/samv3)
protocol. One particularity of SAM v3.1 is that it does not support ports,
unlike newer versions of SAM (v3.2 and up) that do support them and default the
port numbers to 0. From the point of view of peers that use newer versions of
SAM or other protocols that support ports, a SAM v3.1 peer is connecting to them
on port 0, from source port 0.
To allow future upgrades to newer versions of SAM, Hush sets its
listening port to 0 when listening for incoming I2P connections and advertises
its own I2P address with port 0. Furthermore, it will not attempt to connect to
I2P addresses with a non-zero port number because with SAM v3.1 the destination
port (`TO_PORT`) is always set to 0 and is not in the control of Hush.
## Bandwidth
I2P routers may route a large amount of general network traffic with their
default settings. Check your router's configuration to limit the amount of this
traffic relayed, if desired.
With `i2pd`, the amount of bandwidth being shared with the wider network can be
adjusted with the `bandwidth`, `share` and `transittunnels` options in your
`i2pd.conf` file. For example, to limit total I2P traffic to 256KB/s and share
50% of this limit for a maximum of 20 transit tunnels:
```
bandwidth = 256
share = 50
[limits]
transittunnels = 20
```
If you prefer not to relay any public I2P traffic and only permit I2P traffic
from programs which are connecting via the SAM proxy, e.g. Hush, you
can set the `notransit` option to `true`.
Similar bandwidth configuration options for the Java I2P router can be found in
`http://127.0.0.1:7657/config` under the "Bandwidth" tab.

297
doc/tor.md
View File

@@ -1,154 +1,225 @@
# Warning
# Tor
Do not assume Tor support works perfectly in Hush; better Tor support is currently being worked on.
# Hush + Tor
It is possible to run Hush as a Tor hidden service, and connect to such services.
It is possible to run Hush as a Tor onion service, and connect to such services.
The following directions assume you have a Tor proxy running on port 9050. Many distributions default to having a SOCKS proxy listening on port 9050, but others may not. In particular, the Tor Browser Bundle defaults to listening on port 9150. See [Tor Project FAQ:TBBSocksPort](https://www.torproject.org/docs/faq.html.en#TBBSocksPort) for how to properly
configure Tor.
## Compatibility
1. Run Hush behind a Tor proxy
-------------------------------
- Starting with version 3.9.3, Hush only supports Tor version 3 hidden
services (Tor v3). Tor v2 addresses are ignored by Hush and neither
relayed nor stored.
The first step is running Hush behind a Tor proxy. This will already make all
outgoing connections be anonymized, but more is possible.
- Tor removed v2 support beginning with version 0.4.6.
-proxy=ip:port Set the proxy server. If SOCKS5 is selected (default), this proxy
server will be used to try to reach .onion addresses as well.
## How to see information about your Tor configuration via Hush
-onion=ip:port Set the proxy server to use for Tor hidden services. You do not
need to set this if it's the same as -proxy. You can use -noonion
to explicitly disable access to hidden service.
There are several ways to see your local onion address in Hush:
- in the "Local addresses" output of CLI `-netinfo`
- in the "localaddresses" output of RPC `getnetworkinfo`
- in the debug log (grep for "AddLocal"; the Tor address ends in `.onion`)
-listen When using -proxy, listening is disabled by default. If you want
to run a hidden service (see next section), you'll need to enable
it explicitly.
You may set the `-debug=tor` config logging option to have additional
information in the debug log about your Tor configuration.
-connect=X When behind a Tor proxy, you can specify .onion addresses instead
-addnode=X of IP addresses or hostnames in these parameters. It requires
-seednode=X SOCKS5. In Tor mode, such addresses can also be exchanged with
other P2P nodes.
CLI `-addrinfo` returns the number of addresses known to your node per
network. This can be useful to see how many onion peers your node knows,
e.g. for `-onlynet=onion`.
To fetch a number of onion addresses that your node knows, for example seven
addresses, use the `getnodeaddresses 7 onion` RPC.
## 1. Run Hush behind a Tor proxy
The first step is running Hush behind a Tor proxy. This will already anonymize all
outgoing connections, but more is possible.
-proxy=ip:port Set the proxy server. If SOCKS5 is selected (default), this proxy
server will be used to try to reach .onion addresses as well.
You need to use -noonion or -onion=0 to explicitly disable
outbound access to onion services.
-onion=ip:port Set the proxy server to use for Tor onion services. You do not
need to set this if it's the same as -proxy. You can use -onion=0
to explicitly disable access to onion services.
------------------------------------------------------------------
Note: Only the -proxy option sets the proxy for DNS requests;
with -onion they will not route over Tor, so use -proxy if you
have privacy concerns.
------------------------------------------------------------------
-listen When using -proxy, listening is disabled by default. If you want
to manually configure an onion service (see section 3), you'll
need to enable it explicitly.
-connect=X When behind a Tor proxy, you can specify .onion addresses instead
-addnode=X of IP addresses or hostnames in these parameters. It requires
-seednode=X SOCKS5. In Tor mode, such addresses can also be exchanged with
other P2P nodes.
-onlynet=onion Make automatic outbound connections only to .onion addresses.
Inbound and manual connections are not affected by this option.
It can be specified multiple times to allow multiple networks,
e.g. onlynet=onion, onlynet=i2p, onlynet=cjdns.
In a typical situation, this suffices to run behind a Tor proxy:
./hushd -proxy=127.0.0.1:9050
./hushd -proxy=127.0.0.1:9050
If using the Tor Browser Bundle:
## 2. Automatically create a Hush onion service
./hushd -proxy=127.0.0.1:9150
Hush makes use of Tor's control socket API to create and destroy
ephemeral onion services programmatically. This means that if Tor is running and
proper authentication has been configured, Hush automatically creates an
onion service to listen on. The goal is to increase the number of available
onion nodes.
This feature is enabled by default if Hush is listening (`-listen`) and
it requires a Tor connection to work. It can be explicitly disabled with
`-listenonion=0`. If it is not disabled, it can be configured using the
`-torcontrol` and `-torpassword` settings.
To see verbose Tor information in the hushd debug log, pass `-debug=tor`.
### Control Port
You may need to set up the Tor Control Port. On Linux distributions there may be
some or all of the following settings in `/etc/tor/torrc`, generally commented
out by default (if not, add them):
```
ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1
```
Add or uncomment those, save, and restart Tor (usually `systemctl restart tor`
or `sudo systemctl restart tor` on most systemd-based systems, including recent
Debian and Ubuntu, or just restart the computer).
On some systems (such as Arch Linux), you may also need to add the following
line:
```
DataDirectoryGroupReadable 1
```
### Authentication
Connecting to Tor's control socket API requires one of two authentication
methods to be configured: cookie authentication or hushd's `-torpassword`
configuration option.
#### Cookie authentication
For cookie authentication, the user running hushd must have read access to
the `CookieAuthFile` specified in the Tor configuration. In some cases this is
preconfigured and the creation of an onion service is automatic. Don't forget to
use the `-debug=tor` hushd configuration option to enable Tor debug logging.
If a permissions problem is seen in the debug log, e.g. `tor: Authentication
cookie /run/tor/control.authcookie could not be opened (check permissions)`, it
can be resolved by adding both the user running Tor and the user running
hushd to the same Tor group and setting permissions appropriately.
On Debian-derived systems, the Tor group will likely be `debian-tor` and one way
to verify could be to list the groups and grep for a "tor" group name:
```
getent group | cut -d: -f1 | grep -i tor
```
You can also check the group of the cookie file. On most Linux systems, the Tor
auth cookie will usually be `/run/tor/control.authcookie`:
```
TORGROUP=$(stat -c '%G' /run/tor/control.authcookie)
```
Once you have determined the `${TORGROUP}` and selected the `${USER}` that will
run hushd, run this as root:
```
usermod -a -G ${TORGROUP} ${USER}
```
Then restart the computer (or log out) and log in as the `${USER}` that will run
hushd.
#### `torpassword` authentication
For the `-torpassword=password` option, the password is the clear text form that
was used when generating the hashed password for the `HashedControlPassword`
option in the Tor configuration file.
The hashed password can be obtained with the command `tor --hash-password
password` (refer to the [Tor Dev
Manual](https://2019.www.torproject.org/docs/tor-manual.html.en) for more
details).
## 3. Manually create a Hush onion service
2. Run a Hush hidden server
----------------------------
You can also manually configure your node to be reachable from the Tor network.
Add these lines to your `/etc/tor/torrc` (or equivalent config file):
If you configure your Tor system accordingly, it is possible to make your node also
reachable from the Tor network. Add these lines to your /etc/tor/torrc (or equivalent
config file):
HiddenServiceDir /var/lib/tor/hush-service/
HiddenServicePort 18030 127.0.0.1:18032
HiddenServiceDir /var/lib/tor/hush-service/
HiddenServicePort 18030 127.0.0.1:18030
The directory can be different of course, but virtual port numbers should be equal to
your hushd's P2P listen port (18030 by default), and target addresses and ports
should be equal to binding address and port for inbound Tor connections (127.0.0.1:18032 by default).
The directory can be different of course, but (both) port numbers should be equal to
your hushd's P2P listen port (18030 by default).
-externalip=X You can tell hush about its publicly reachable addresses using
this option, and this can be an onion address. Given the above
configuration, you can find your onion address in
/var/lib/tor/hush-service/hostname. For connections
coming from unroutable addresses (such as 127.0.0.1, where the
Tor proxy typically runs), onion addresses are given
preference for your node to advertise itself with.
-externalip=X You can tell Hush about its publicly reachable address using
this option, and this can be a .onion address. Given the above
configuration, you can find your onion address in
/var/lib/tor/hush-service/hostname. Onion addresses are given
preference for your node to advertize itself with, for connections
coming from unroutable addresses (such as 127.0.0.1, where the
Tor proxy typically runs).
You can set multiple local addresses with -externalip. The
one that will be rumoured to a particular peer is the most
compatible one and also using heuristics, e.g. the address
with the most incoming connections, etc.
-listen You'll need to enable listening for incoming connections, as this
is off by default behind a proxy.
-listen You'll need to enable listening for incoming connections, as this
is off by default behind a proxy.
-discover When -externalip is specified, no attempt is made to discover local
IPv4 or IPv6 addresses. If you want to run a dual stack, reachable
from both Tor and IPv4 (or IPv6), you'll need to either pass your
other addresses using -externalip, or explicitly enable -discover.
Note that both addresses of a dual-stack system may be easily
linkable using traffic analysis.
-discover When -externalip is specified, no attempt is made to discover local
IPv4 or IPv6 addresses. If you want to run a dual stack, reachable
from both Tor and IPv4 (or IPv6), you'll need to either pass your
other addresses using -externalip, or explicitly enable -discover.
Note that both addresses of a dual-stack system may be easily
linkable using traffic analysis.
In a typical situation, where you're only reachable via Tor, this should suffice:
./hushd -proxy=127.0.0.1:9050 -externalip=hushc0de123.onion -listen
./hushd -proxy=127.0.0.1:9050 -externalip=7zvj7a2imdgkdbg4f2dryd5rgtrn7upivr5eeij4cicjh65pooxeshid.onion -listen
(obviously, replace the Onion address with your own). Currently only v2 HS's are supported.
It should be noted that you still listen on all devices and another node could establish a clearnet connection, when knowing
(obviously, replace the .onion address with your own). It should be noted that you still
listen on all devices and another node could establish a clearnet connection, when knowing
your address. To mitigate this, additionally bind the address of your Tor proxy:
./hushd ... -bind=127.0.0.1
./hushd ... -bind=127.0.0.1
If you don't care too much about hiding your node, and want to be reachable on IPv4
as well, use `discover` instead:
./hushd ... -discover
./hushd ... -discover
and open port 18030 on your firewall.
and open port 18030 on your firewall (or use port mapping, i.e., `-upnp` or `-natpmp`).
If you only want to use Tor to reach onion addresses, but not use it as a proxy
If you only want to use Tor to reach .onion addresses, but not use it as a proxy
for normal IPv4/IPv6 communication, use:
./hushd -onion=127.0.0.1:9050 -externalip=hushc0de123.onion -discover
./hushd -onion=127.0.0.1:9050 -externalip=7zvj7a2imdgkdbg4f2dryd5rgtrn7upivr5eeij4cicjh65pooxeshid.onion -discover
## 4. Privacy recommendations
3. Automatically listen on Tor
--------------------------------
Starting with Tor version 0.2.7.1 it is possible, through Tor's control socket
API, to create and destroy 'ephemeral' hidden services programmatically.
Hush has been updated to make use of this.
This means that if Tor is running (and proper authentication has been configured),
Hush automatically creates a hidden service to listen on. Hush will also use Tor
automatically to connect to other .onion nodes if the control socket can be
successfully opened. This will positively affect the number of available .onion
nodes and their usage.
This new feature is enabled by default if Hush is listening (`-listen`), and
requires a Tor connection to work. It can be explicitly disabled with `-listenonion=0`
and, if not disabled, configured using the `-torcontrol` and `-torpassword` settings.
To show verbose debugging information, pass `-debug=tor`.
Connecting to Tor's control socket API requires one of two authentication methods to be
configured. For cookie authentication the user running hushd must have write access
to the `CookieAuthFile` specified in Tor configuration. In some cases this is
preconfigured and the creation of a hidden service is automatic. If permission problems
are seen with `-debug=tor` they can be resolved by adding both the user running tor and
the user running hushd to the same group and setting permissions appropriately. On
Debian-based systems the user running hushd can be added to the debian-tor group,
which has the appropriate permissions. An alternative authentication method is the use
of the `-torpassword` flag and a `hash-password` which can be enabled and specified in
Tor configuration.
4. Connect to a Hush hidden server
-----------------------------------
To test your set-up, you might want to try connecting via Tor on a different computer to just a
a single Hush hidden server. Launch hushd as follows:
./hushd -onion=127.0.0.1:9050 -connect=fuckzookoie6wxgio.onion
Now use hush-cli to verify there is only a single peer connection.
hush-cli getpeerinfo
[
{
"id" : 1,
"addr" : "zcashhoneypot.onion:18030",
...
"version" : 1987420,
"subver" : "/GoldenSandtrout:3.6.0/",
...
}
]
To connect to multiple Tor nodes, use:
./hushd -onion=127.0.0.1:9050 -addnode=hushbeef123.onion -dnsseed=0 -onlynet=onion
- Do not add anything but Hush ports to the onion service created in section 3.
If you run a web service too, create a new onion service for that.
Otherwise it is trivial to link them, which may reduce privacy. Onion
services created automatically (as in section 2) always have only one port
open.