BM still listens for inbound connections when connected through tor, green "light" is on.

[yurivict]

Instance is configured to connect through SOCKS5/tor. "Listen for connections on port" is grayed out. Incoming connections should be disabled (because there is no HS support yet). Yet it shows the green light that means that there are incoming connections. netstat shows that it listens on the port that is grayed out by SOCKS5 option.

This is wrong because SOCKS5 forwards connections out to some other host with different IP, yet listening and incoming connections indicate that the real IP is exposed.

This is a security problem.

[PeterSurda]

There is a setting in the keys.dat, sockslisten, which controls whether it listens for incoming connections when proxy is SOCKS4 or SOCKS5. In the GUI, this is represented by the "Listen for incoming connections when using proxy" checkbox.

This will be slightly reworked when HS support is implemented to allow more flexibility.

[PeterSurda]

Recently I implemented hidden service support. Here is the documentation: https://bitmessage.org/wiki/FAQ#How_do_I_setup_Bitmessage_as_a_hidden_service_on_Tor
Depending on configuration, you can listen on clearnet, on hidden service or on both at the same time. There is no GUI for this yet but you can manually edit keys.dat.

[dogtopus]

Bitmessage still listens on the port globally even if onionbindip was set to 127.0.0.1 and sockslisten was false. Also it seems that Bitmessage doesn't use onionport at all but still follows the normal port setting.

[yurivict]

This is a security problem, because once the user asks for tor connection (onion* anything) he has the expectation of BM using tor instead of the clearnet. And the open port is an indication of the clearnet use.

I also don't like terms like "onionbindip" because they aren't self-explanatory. It looks like this is an expert term, and the user is expected to possess some expect knowledge, when in fact the decision is only "use tor" vs. "use clearnet".

[PeterSurda]

@dogtopus You also need to specify onionhostname and it needs to include .onion, that's probably what's missing. Also, onionport is the external tor port, not the internal listening port. When you for example have

HiddenServicePort 12345 127.0.0.1:8444

in your torrc, then 12345 is the onionport and 8444 is port in keys.dat.

[PeterSurda]

@yurivict PyBitmessage needs to know the tor hidden service configuration, because otherwise it doesn't know what port and hostname to advertise and noone will be able to connect to it. It is an expert setting, at least for the time being. For outgoing settings over tor, this is not necessary.

But there maybe something else wrong, I'll do some tests.

[yurivict]

Tor has the control port. BM can add onions through that control port.
But, to access the control port you need to have a permission, and it also should be configured to be "on". So this can be done automatically, but requires some configuration change.

[PeterSurda]

Tor has the control port. BM can add onions through that control port.

... and there is no standardised way to obtain this port, so you need to configure it anyway.

Besides, I don't believe that you should setup PyBitmessage as an onion service unless you know what you're doing. It does not improve your speed or anonymity, rather it helps other tor users. And if it's not working correctly, you'll just end up slowing others because they'll waste time timeouting.

[yurivict]

torrc should have ControlPort 9051 line to enable it.
And there is the "stem" python library that allows you to access it: https://stem.torproject.org/faq.html

So there is an easy way to access it.

As for the timeouts, this is a bug in BM. When the BM instance starts, it should register either as a clearnet host (ip:port), as an onion host (xxxxxx.onion), or as both. Onion peers can access both clearnet and other onion peers, clearnet peers can access only other clearnet peers.

It is done this way in ZeroNet actually - and works quite well.

[PeterSurda]

torrc should have ControlPort 9051 line to enable it.

That makes too many assumptions. I don't have it turned on anywhere, and I also have setups with tor and BM on different machines. I also don't want PyBitmessage to randomly connect to ports to probe whether this or that is turned on (I'm already unhappy about probing for namecoin). I also think that if you know how to edit the torrc to enable ControlPort, you should also be able to create a new onion address.

If you bundle tor with PyBitmessage, that's a different case, then you have more control over deployment, but I don't have immediate plans for that.

As for the timeouts, this is a bug in BM.

Where exactly is the bug?

When the BM instance starts, it should register either as a clearnet host (ip:port), as an onion host (xxxxxx.onion), or as both. Onion peers can access both clearnet and other onion peers, clearnet peers can access only other clearnet peers.

This is how it works now, except it doesn't know its external IP address (say if you're behind NAT), that is determined by the other party. But this doesn't work with onion addresses since there the IP address is always the internal IP of the tor instance, so you need to make sure your tor and PyBitmessage agree on the setup.