Bitcoin behind Tor still receiving connections on 8333 (identity leak)

[EhVedadoOAnonimato]

I noticed that my bitcoin client was getting too many connections (> 70), what's weird since I had put it behind Tor (I don't want anyone linking my IP to my transactions).

I ran a "netstat -ap | grep bitcoin" and saw that bitcoin was bypassing my proxy configuration, opening my local port 8333 and accepting incoming connections on it. What's more troubling is that, not only it is listening when it should not, but it must be giving away my IP somehow, since all these other peers would not find me otherwise - they would try to connect to the exit-nodes, in vain. Maybe it's accessing the IRC bootstrap channel without using the proxy?

I'm using version 0.5 now. I had not noticed such behavior before, so it is a regression, but I can't tell which version introduced it.

[laanwj]

This sounds like a regression; if tor is used it should disable listening, and should not even know its own external IP address, let alone broadcast to others.

Can you check whether the proxy is used at all?

[EhVedadoOAnonimato]

I can see by netstat that the proxy is used. There are connections opened by bitcoin, from localhost:X to localhost:9050.

[iongchun]

It should not be assumed all SOCKS proxies are TOR, thus disable listening.
For example, I might want to setup a SSH tunnel between bitcoind and remote external server using both SOCKS proxy and port forwarding from server.

[laanwj]

Well it makes no sense to listen on the local IP address if a proxy is used, tor or not -- you have delegated network access to that remote host. Someone using an anonymous non-TOR SOCKS proxy will still not want to leak his iP address, it is a serious leak.

In ancient times I've done something with SOCKS proxies, and I know SOCKS5 supports a "bind" call to be able to listen on a the proxy host. This is what ideally should be used in these kind of cases, but I also know 0% of the programs actually implementing a socks proxy support it.

So the second-best thing is to disable listening (by default -- one may enable it in specific cases) when a proxy is used. BTW if you set your TOR port to the default of 9050 it will automatically regard it as TOR. Did you change the port? that might explain the regression:

bool fTOR = (fUseProxy && addrProxy.port == htons(9050));

IMO this should be an explicit option in the UI, and not some heuristic based on the port.

Anyway, for now you can try if --nolisten command line option solves the problem.

[EhVedadoOAnonimato]

I can't try the -nolisten switch right now, will do it as soon as I can.

My Tor is on 9050, as by default.

Am I the only one having this problem?

[iongchun]

I also use TOR, but never notice the listening port, because my node is behind firewall, and never connected from outside ;)
I just check the source, notice that in init.cpp, fUseProxy and addrProxy is checked before it is initialized, I guess this is the bug.

[laanwj]

(oops, github was a bit trigger happy)

Yes this could be the problem, the value of fUseProxy is only "final" after LoadWallet and the command line option -proxy have been parsed (in that order).

fTOR however is given a value before either the fUseProxy or the proxy port has been assigned. I am not sure how this can ever have worked.

See this pull request: #663
Or here: https://github.com/laanwj/bitcoin/tree/torcheckfix

Can you test this?

[iongchun]

You do notice fNoListen is used before assigned, right? ;)
I would suggest move the "-proxy" parsing before fTOR and fNoListen initializtion.

[laanwj]

Huh good catch :)

But that wouldn't work either -- fUseProxy is also set by LoadWallet, so it can only be parsed after that, as the command-line option should take precedence over what is set in the UI.

Anything using fUseProxy must happen after LoadWallet.

This is more annoying than I thought... we need to be really sure to fix this without introducing a new regression

[iongchun]

BTW, despite this bug, I do not see why EhVedadoOAnonimato have connections on the listening port,
since proxy should still be used, and IRC server only see IP of the proxy.
Maybe your Bitcoin node is also a TOR exit, EhVedadoOAnonimato? Or do you have UPnP enabled and in use?

And I think fHaveUPnP should also not be set when fNoListen is false.

[iongchun]

Wow... storing settings in the wallet... I always wonder why my proxy setting is not in bitcoin.conf.

[laanwj]

Yeah it's and it's one of the things complicating multi-wallet support

All the UI-configured settings are written into the wallet. The .conf is never written, only read.

[laanwj]

Ok, let's see what really happens in init.cpp, proxy-wallet related. Current order of events:

1. fTOR set based on fUseProxy and addrProxy.port (precondition: fUseProxy and addrProxy have their final value !!not met!!, postcondition: fTor has its final value)
2. fNoListen is set based on GetBoolArg("-nolisten") and fTOR (precondition: fTor has its final value, postcondition: fNoListen has its final value)
3. if fNoListen is not set, BindListenPort is called (precondition: fNoListen has its final value)
4. LoadWallet loads wallet (postcondition: fUseProxy and addrProxy have an initial value)
5. fUseProxy and addrProxy are parsed from mapArgs["-proxy"] (postcondition: fUseProxy and addrProxy have their final value)
6. Network thread is started (StartNode) (precondition: all network settings have their final value)

So we have to try to reorder this in a sensible order. Constraint: Binding to a port happens early because "Bind to the port early so we can tell if another instance is already running.".

[TheBlueMatt]

Well from what I can see we have to drop the binding port early to see if another instance is running. I dont think it is a big deal as we now have nice locks in .bitcoin, whereas (IIRC) those weren't there when the order of BindListenPort was written by satoshi, but maybe gavin can confirm that.

[laanwj]

I agree, we already stopped using port binding as a locking mechanism when
-nolisten was introduced.

[EhVedadoOAnonimato]

I'm sorry for not having reported back.

I confirm that the -nolisten switch seems to fix the issue. At least when I add it, there are no incoming connections and bitcoin is not listening on 8333.

@Iongshun, concerning the incoming connections, when I first installed bitcoin (there's a while), I manually configured my router to redirect connections on 8333 to my machine, so that explains how people could reach me. That doesn't explain how they knew there was a bitcoin running on my IP though. Or do bitcoin nodes store IPs of nodes they see once and keep trying to connect to it for a long time? Because than perhaps my Android phone is to blame: I have the BitcoinJ based app on it, and I run it behind the same router (so, the same IP), without Tor...

[TheBlueMatt]

Yes all nodes keep a list of known-good ips to try and exchange those with each other.

EhVedadoOAnonimato reply@reply.github.com wrote:

I'm sorry for not having reported back.

I confirm that the -nolisten switch seems to fix the issue. At least
when I add it, there are no incoming connections and bitcoin is not
listening on 8333.

@Iongshun, concerning the incoming connections, when I first installed
bitcoin (there's a while), I manually configured my router to redirect
connections on 8333 to my machine, so that explains how people could
reach me. That doesn't explain how they knew there was a bitcoin
running on my IP though. Or do bitcoin nodes store IPs of nodes they
see once and keep trying to connect to it for a long time? Because than
perhaps my Android phone is to blame: I have the BitcoinJ based app on
it, and I run it behind the same router (so, the same IP), without
Tor...

---

Reply to this email directly or view it on GitHub:
#659 (comment)