Seeding via Tor fails #825

New Issue

2015-11-20T16:15:49+01:00

i2p-lbt commented

2015-11-20 16:15:49 +01:00

(Migrated from github.com)

I decided to test Bitmessage. Having a Tor Router running I used the mechanism provided by #278 to setup a TOR proxy before the first connection, closing and restarting the application afterwards. The client then tried to establish some connections, which all failed. Double-checking that the router is running and accessible I after all had to let the client run shortly (below a minute) on the ClearNet (without a proxy set), where it successfully made connections. After setting up the proxy and restarting again, the client then seems to work as expected via the proxy.

Not knowing the internals, I assume there are some addresses setup in the source which the client uses for it's first connections. I'm unsure why these fail via Tor but not on the ClearNet. A possible reason that comes to mind is if those addresses would be blocking Tor (e.g. hosting via CloudFlare). Could of course be someone else (providers) blocking somewhere in-between. This is not necessarily known to the operators btw.

However, the mechanism to setup a proxy before first connecting is desirable, but didn't work for me. Not sure to address this properly in ClearNet, but you might want to investigate as the mechanism would be useless if this happens to all users (not sure about that, just tested this for about an hour before trying to seed via ClearNet and then returning to Tor). A good solution might be to host a server (daemon) running on Tor using an Onion address and including that address in the source-seed?

I decided to test Bitmessage. Having a Tor Router running I used the mechanism provided by #278 to setup a TOR proxy before the first connection, closing and restarting the application afterwards. The client then tried to establish some connections, which all failed. Double-checking that the router is running and accessible I after all had to let the client run shortly (below a minute) on the ClearNet (without a proxy set), where it successfully made connections. After setting up the proxy and restarting again, the client then seems to work as expected via the proxy. Not knowing the internals, I assume there are some addresses setup in the source which the client uses for it's first connections. I'm unsure why these fail via Tor but not on the ClearNet. A possible reason that comes to mind is if those addresses would be blocking Tor (e.g. hosting via CloudFlare). Could of course be someone else (providers) blocking somewhere in-between. This is not necessarily known to the operators btw. However, the mechanism to setup a proxy before first connecting is desirable, but didn't work for me. Not sure to address this properly in ClearNet, but you might want to investigate as the mechanism would be useless if this happens to all users (not sure about that, just tested this for about an hour before trying to seed via ClearNet and then returning to Tor). A good solution might be to host a server (daemon) running on Tor using an Onion address and including that address in the source-seed?

PeterSurda commented

2015-11-20 16:37:31 +01:00

(Migrated from github.com)

If I had to guess, I would say that the bootstrapping nodes see too many connections through the TOR exit nodes. PyBitmesage won't allow more than one connection per IP.

I have no control over the bootstrap nodes and I don't know who operates them. I also don't know how the DNS bootstrap is updated (and if).

@Atheros1 Perhaps the bootstrap nodes should accept more than one connection per IP, and only provide the current active node list and then immediately disconnect?

If I had to guess, I would say that the bootstrapping nodes see too many connections through the TOR exit nodes. PyBitmesage won't allow more than one connection per IP. I have no control over the bootstrap nodes and I don't know who operates them. I also don't know how the DNS bootstrap is updated (and if). @Atheros1 Perhaps the bootstrap nodes should accept more than one connection per IP, and only provide the current active node list and then immediately disconnect?

PeterSurda commented

2015-11-20 16:41:00 +01:00

(Migrated from github.com)

Another alternative would be to run a seed nodes over Tor and add Tor address support to BM (in addition to IPv4 and IPv6 addresses).

i2p-lbt commented

2015-11-21 13:24:46 +01:00

(Migrated from github.com)

Another alternative would be to run a seed nodes over Tor and add Tor address support to BM (in addition to IPv4 and IPv6 addresses).

That could allow kind of "bridging" then, i.e. running a server with two "interfaces"? If you go that road, I'd be interested in looking into supporting I2P as well. Tor addresses are like aauywtawnerpauywqawner.onion and I2P are like aauywtawnerpauywqawner.b32.i2p. Both require using an according proxy, so there actually shouldn't be much difference I guess? That could allow running bridges like ClearNet/Tor, ClearNet/I2P, Tor/I2P, then, in addition to just one of those, which sounds interesting. Would make the UI a bit more complex though, I assume. But a communication infrastructure stretching over all of those might be desirable?

> Another alternative would be to run a seed nodes over Tor and add Tor address support to BM (in addition to IPv4 and IPv6 addresses). That could allow kind of "bridging" then, i.e. running a server with two "interfaces"? If you go that road, I'd be interested in looking into supporting [I2P](https://geti2p.net/en/) as well. Tor addresses are like aauywtawnerpauywqawner.onion and I2P are like aauywtawnerpauywqawner.b32.i2p. Both require using an according proxy, so there actually shouldn't be much difference I guess? That could allow running bridges like ClearNet/Tor, ClearNet/I2P, Tor/I2P, then, in addition to just one of those, which sounds interesting. Would make the UI a bit more complex though, I assume. But a communication infrastructure stretching over all of those might be desirable?

PeterSurda commented

2015-11-21 14:04:48 +01:00

(Migrated from github.com)

I think adding I2P and Tor is more complex. There actually is an I2P fork of PyBitmessage: https://github.com/metamarcdw/PyBitmessage-I2P, but it's not compatible with the clearnet PyBitmessage versions.

By 0.6 I can maybe implement an optional "IP-Seed mode" like I described and then ask the seed nodes to upgrade. That is much less complex in comparison and also easier for me to test.

I think adding I2P and Tor is more complex. There actually is an I2P fork of PyBitmessage: https://github.com/metamarcdw/PyBitmessage-I2P, but it's not compatible with the clearnet PyBitmessage versions. By 0.6 I can maybe implement an optional "IP-Seed mode" like I described and then ask the seed nodes to upgrade. That is much less complex in comparison and also easier for me to test.

Klexx commented

2015-11-22 03:29:28 +01:00

(Migrated from github.com)

I had some problems with Tor too. The Tor logfile showed, that Tor is blocking the DNS request. I simply replaced the Bootstrap Server Name with the IP. Worked for me.

(I think the GUI needs a way to add and/or edit BootstrapNodes / trustedpeer / IPs anyway)

I had some problems with Tor too. The Tor logfile showed, that Tor is blocking the DNS request. I simply replaced the Bootstrap Server Name with the IP. Worked for me. (I think the GUI needs a way to add and/or edit BootstrapNodes / trustedpeer / IPs anyway)

PeterSurda commented

2015-11-27 02:49:36 +01:00

(Migrated from github.com)

Latest mailchuck master allows DNS bootstrapping over Tor's SOCKS proxy. This may help a bit (I don't know who manages the DNS bootstrap, if it's not dynamic then these servers may become full as well).

I also did some tests on allowing to seed through Tor directly from a node that runs a hidden service, but I was unable to make it work. But I think that in the future, direct Tor support can be implemented and you will be able to run BM as a hidden service.

Latest mailchuck master allows DNS bootstrapping over Tor's SOCKS proxy. This may help a bit (I don't know who manages the DNS bootstrap, if it's not dynamic then these servers may become full as well). I also did some tests on allowing to seed through Tor directly from a node that runs a hidden service, but I was unable to make it work. But I think that in the future, direct Tor support can be implemented and you will be able to run BM as a hidden service.

PeterSurda commented

2015-11-27 13:54:16 +01:00

(Migrated from github.com)

I now also added seeding through Tor directly (hidden service) via a modified BM that I run. This BM will accept an unlimited number of connections from Tor, will not provide the initial inventory synchronisation (so that it saves bandwidth), only addr sync, and it will disconnect Tor users after 2 minutes. Within 2 minutes you should be able to get all the addresses (at the moment that's like 70kB on disk, on wire it is even less). There actually wasn't much code needed for this, in particular on the client, but there was a lot of debugging. If you still experience problems, let me know.

This repo is archived. You cannot comment on issues.