[tor-dev] Potential regression when binding sockets to interface without default route

[René Mayrhofer]

Wow, thanks for the quick and detailed answer!

Am 2016-09-19 um 16:32 schrieb teor:
> This isn't the default setup, but it's actually quite common,
> particularly for Exit relays that want to segregate their outbound
> traffic from their public relay address.
Good to know that we aren't doing anything that's too far off the normal
case.

>> root at tor2 ~ # grep 193.171.202 /etc/tor/torrc
>> ORPort 193.171.202.146:9001
>> ORPort 193.171.202.146:443
>> OutboundBindAddress 193.171.202.150
>> DirPort 193.171.202.146:9030
> Since you don't set your IPv4 address using Address, this means that Tor tries to guess your address.
> On a machine with multiple IPv4 addresses, this means it might not guess the address you expect.
>
> I think that 0.2.5 only looked at the first interface the OS returned, and that happened to be the one you wanted. But guessing using interface addresses is never going to be reliable on multi-IPv4 machines.
>
> Between 0.2.5 and 0.2.8, the address guessing code was modified several times. It now looks at all your local network interfaces to guess the address. I think there was an unintentional ordering change. We can fix that (see below).
Thanks for the detailed explanation. It is now clearer to me that we
should have set Address all along (I misinterpreted the option in the
beginning, thinking only of NAT cases).

>> Sep 19 11:37:41.199 [notice] Opening Socks listener on 0.0.0.0:9050
> I hope you have a SOCKSPolicy in place (or the equivalent firewall rules), otherwise anyone can use your relay as an unencrypted, open proxy.
Yes, both ;) We intentionally use that exit node as an entry for some
clients directly at the institute, mostly for two reasons: a) we like
the eat-your-own-dog-food policy: if the node stops accepting traffic at
all, we should notice fairly quickly even without our monitoring systems
alerting anybody (although both did not catch this particular case, and
we are working on adding more monitoring rules to catch that in the
future...); and b) to increase the k in k-anonymity specifically for
this node. Incoming traffic could be from anybody, including ourselves,
so that's an additional reason not to (be forced to) monitor (an
admittedly weak legal defense, but it may assist at some future point).

> This is an interesting edge-case: Tor doesn't (and likely can't) check
> that the ORPort a client thinks it is connecting to, is the same as
> the one it just advertised. So the ORPort reachability check succeeded
> on your relay, because some clients still had the old address in the
> old descriptor. And Tor never repeats the check. 
Interesting. I admit it did lead me on a false trail during debugging
(we checked some hops in between to see if they started blocking port
9030 before resorting to rolling back, which is when I noticed the
different log messages - and it didn't help that nmap doesn't have 9030
in it's default TCP ports list either...).

> Tor can't actually use the bind address for reachability checks, because there's only one IPv4 address in a relay descriptor, and that's the one that other tor instances will try to connect to. Also, what if the ORPort and DirPort are on different addresses? What if the relay is behind a NAT?
That's a lot clearer to me now. Thanks.

best regards,
Rene


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160920/775e34b7/attachment-0001.sig>