Tor hidden service support

sipa commented at 3:47 pm on May 1, 2012: member

(extends #1141 (proxy improvements) and #1021 (ipv6 support)

Adds support for running as and connecting to Tor hidden services. *.onion addresses are mapped into the IPv6 range in the same way as OnionCat does.

See doc/Tor.txt for more information.

sipa commented at 4:41 pm on May 1, 2012: member

If someone wants to test (use -connect= or -addnode=), I run a bitcoind hidden service on a57qr3ydpnyntf5k.onion:8333.

gavinandresen commented at 4:50 pm on May 1, 2012: contributor

Cool!

Can you add a doc/Tor.txt with “how to run your bitcoin node as a hidden service” info in it?

laanwj commented at 7:38 pm on May 1, 2012: member

Nice!

rebroad commented at 5:34 pm on May 2, 2012: contributor

Fantastic! thanks sipa.

rebroad commented at 5:43 pm on May 2, 2012: contributor

Hi sipa, I’d like to help test this. I could do with some help using git to apply this patch though. I was wanting to offer a bounty for git help, but I don’t have post access on bitcoinforum…, and constantly using meld is becoming a bit too time consuming… :-s

sipa commented at 1:44 am on May 3, 2012: member

@rebroad: switch to whatever branch you want my patches to be merged with (possibly just master), and type “git pull git://github.com/sipa/bitcoin.git torhs”.

rebroad commented at 11:44 am on May 3, 2012: contributor

@sipa Thanks. doing that now. Has -addnode code been removed from init.cpp, or am I misreading the merge conflict?

sipa commented at 12:00 pm on May 3, 2012: member

It’s not removed; only the code in init.cpp that added -addnode nodes to addrman was removed (the actual processing of -addnode is in ThreadOpenAddedConnections2 in net.cpp.

sipa commented at 12:48 pm on May 3, 2012: member

By the way: what are you merging with, that you get a conflict?

rebroad commented at 2:10 pm on May 3, 2012: contributor

Couple of questions. Why do I get:

Cannot connect to a57qr3ydpnyntf5k.onion:8333: unsupported network

whereas other onion address work? (the above onion address is the one you mentioned in this pull).

Also, re:-

receive version message: version 50200, blocks=178423, us=127.0.0.1:47146, them=106.187.36.183:28333, peer=siqdznszjf4e6v5j.onion:8333

Does this mean bitcoin exposes nodes’ actual IP address, despite them thinking they’re running an anonymous onion service?

Also, in the above example, what does it do with the “us” address? Shouldn’t it be using my .onion address instead…?

sipa commented at 5:25 pm on May 3, 2012: member

That “unsupported network” error means you’re trying to connect to an onion address directly (not through a proxy). Is it possible you didn’t use -proxy?

That received version message means that you connected to siqdznszjf4e6v5j.onion:8333, and thereby reached a peer who thinks you are 127.0.0.1 (so it came from their Tor proxy), and believes he has address 106.187.36.183. Which version was the peer running? Recent versions shouldn’t announce 127.0.0.1 as their own address, and if the other node also ran this torhs branch, if it was running using -externalip=….onion, it should report its onion address instead.

Edit: obviously, the peer is running 0.5.2 (as it reports protocol version 50200). If you’d connect to a 0.6.0 or torhs node, you’ll see different behaviour.

rebroad commented at 9:42 pm on May 3, 2012: contributor

receive version message: version 60000, blocks=178480, us=127.0.0.1:56334, them=24.7.178.63:8333, peer=p2hwc26zdsrqxiix.onion:8333

Seems pretty similar for a 0.6.0 too….

gmaxwell commented at 5:32 am on May 4, 2012: contributor

This passes my initial testing. It’s perhaps a little too easy to leak your IP when trying to run as a hidden service. E.g. if you -listen=1 without setting -externalip … still better than what people would get if trying to run a hidden service today, but of course more support will encourage more people to do it. Also, I the fact that proxydns ran when connect was set was kind of surprising, but I guess thats really independent of this pull: connect should probably imply dnsseed=0.

The effective deactivation of anti-dos for incoming onion peers is kind of unfortunate. I wonder if we could do anything about that?

rebroad commented at 12:25 pm on May 4, 2012: contributor

@gmaxwell can you elaborate on what anti-dos you have in mind? ah, you mean such as banning based on IP address. Well, the only way around this would be to make nodes somehow uniquely identifiable. I’m not sure which would be worse, that or lack of ability to ban peers.

gmaxwell commented at 12:40 pm on May 4, 2012: contributor

grep the source for DoS.

rebroad commented at 7:55 pm on May 4, 2012: contributor

@gmaxwell, already did that before my post.

sipa commented at 2:20 pm on May 6, 2012: member

@rebroad the anti-DoS system registers IP addresses which engage in incorrect behavior, and prevents them from connecting or being connected to. In combination with Tor hidden services, you don’t know the source IP, so it cannot be banned.

Mental note: make sure the proxy is never banned.

rebroad commented at 5:03 pm on May 11, 2012: contributor

Hoping this would have been pulled by now… Re IPv6 testing. What would I need to see in debug.log to confirm that this works?

luke-jr commented at 8:08 pm on May 18, 2012: member

Needs rebasing.

sipa commented at 7:32 pm on May 21, 2012: member

Here’s a proposal for a revamping of the relevant command line arguments: https://gist.github.com/2763381

It removes the special casing of :9050 as tor port, and defines more convenient defaults for several options.

sipa commented at 12:28 pm on May 25, 2012: member

Rebased on top #1389.

sipa commented at 10:44 am on June 12, 2012: member

Can I get some ACKs?

Diapolo commented at 1:21 pm on June 12, 2012: none

I’m not the one, who can give an ACK, but are you sure this is rebased on current master? At least ApplyProxySettings() in optionsmodel.cpp seems weird, as I know this function is already there.

It would be also nice, to get a) #1433 in before this (no testing comments currently) or b) I need some infos, what needs to be done for the Tor thing to have all options in the GUI available, so I can update #1433.

in src/netbase.cpp: in cd2d8a4e82 outdated

933-// 0 - unroutable            // 0 - unroutable                 // 0 - unroutable
934-// 1 - teredo                // 1 - teredo                     // 1 - ipv4
935-// 2 - tunneled ipv6         // 2 - tunneled ipv6
936-// 3 - ipv4                  // 3 - ipv6
937-// 4 - ipv6                  // 4 - ipv4
938+// C++ doesn't allow us to inherit from enums

laanwj commented at 7:28 am on June 13, 2012:

Wouldn’t it be saner to just extend the enum? The reason that enums can’t be extended later is that the compiler and programmer can make assumptions on what values to expect. This breaks that assumption.

If there’s a good reason to do it this way (I suppose so) please add a comment describing that.

sipa commented at 12:05 pm on June 13, 2012:

Regarding not extending enums: it’s perfectly sane from a language semantics point of view, in my opinion. enum A { B, C}, enum D : A { E, F } could define B and C as of type enum A, and E and F as of type D, with an implicit conversion between values of enum A to values of enum D.

Reason for not extending the enum here: I prefer not to clutter the public list of networks because one function needs some special cases to deal with.

laanwj commented at 12:39 pm on June 13, 2012:

Yes, it’s ok as long as the values from D do not end up in places where A is supposed to be used. C++ cannot guarantee this, and it wasn’t clear to me on first reading the code that the extended values were local to one function.

Anyway, it seems that you have a good reason, and the extended values are local to that function, please add this in the comment. Just “c++ does not allow this” looks like you’re hacking around something :)

sipa commented at 2:02 pm on June 13, 2012:

Well it is - if C++ would allow extending enums, it wouldn’t need this :)

That said, updated the comment.

sipa commented at 2:03 pm on June 13, 2012: member

Rebased, fixed some sign warnings, and updated a comment as asked by @laanwj.

gavinandresen commented at 3:01 pm on June 18, 2012: contributor

ACK if you make the following edit to doc/Tor.txt:

REPLACE: In a typical situation, this suffices to run behind a Tor proxy:

WITH: These instructions assume that Tor is listening as a SOCKS proxy on port 9050; if you use the Tor Browser Bundle, then it (by default) picks a random port every time it starts. See https://www.torproject.org/docs/faq.html.en#TBBSocksPort for how to properly configure Tor.

Once Tor is configured and running, this suffices to run behind a Tor proxy:

…

gmaxwell commented at 3:02 pm on June 22, 2012: contributor

ACK.

Base32 encoding/decoding c4c99ade65

Unit tests for base32 encode/decode e0be8da392

Diapolo commented at 3:24 pm on June 22, 2012: none

@sipa I would like to make this available for the GUI, can you specify / tell me what is needed?

sipa commented at 3:25 pm on June 22, 2012: member

Rebased and updated documentation a bit. @Diapolo: I’ll explain over IRC if you like.

gavinandresen commented at 10:54 pm on June 22, 2012: contributor

make test_bitcoin is giving me:

test/netbase_tests.cpp:37: error: ‘class CNetAddr’ has no member named ‘IsOnionCat’

Node support for Tor hidden services

This commit adds support for .onion addresses (mapped into the IPv6
by using OnionCat's range and encoding), and the ability to connect
to them via a SOCKS5 proxy.

70f7f00385

Rewrite CNetAddr::GetReachabilityFrom()

Add support for Tor/I2P networks, and make code more readable.

d077dd2a6e

Add -tor and related configuration 54ce3bad64

Debug version messages 863e995b79

Some documentation about tor d789a3f140

sipa commented at 11:14 pm on June 22, 2012: member

Fixed - the function was renamed to IsTor().

gmaxwell referenced this in commit 817ee0d826 on Jun 24, 2012

gmaxwell merged this on Jun 24, 2012

gmaxwell closed this on Jun 24, 2012

Diapolo commented at 3:26 pm on June 24, 2012: none

@sipa: I saw that in the source comments the option -notor is mentioned. Was this left out of the help message in init.cpp by intention?

sipa commented at 3:51 pm on June 24, 2012: member

Some “advanced” usages of options aren’t mentioned. Explaining everything and all combinations would take too much place. Most is quite straightforward though - many options can be prefixed by “no” to disable them already.

Diapolo commented at 4:09 pm on June 24, 2012: none

Thanks for the info and allright then.

coblee referenced this in commit abeca09c08 on Jul 17, 2012

suprnurd referenced this in commit 15cf414967 on Dec 5, 2017

lateminer referenced this in commit fc2636ab78 on Jan 22, 2019

lateminer referenced this in commit b352e2d096 on Dec 25, 2019

DrahtBot locked this on Sep 8, 2021

Tor hidden service support #1174