[tor-relays] Some Dir Authorities blocked

teor teor2345 at gmail.com
Mon Sep 18 02:05:21 UTC 2017


> 
> On 17 Sep 2017, at 17:11, Iain R. Learmonth <irl at torproject.org> wrote:
> 
> The most interesting thing I've discovered so far is that it's common
> for the connections to fail in one direction but then succeed when the
> two relays are reversed. I can't be sure if this is because I can't
> reach one of the relays.

Yes, this would be common, because firewalls are often asymmetric
(many firewalls let relays connect out, but not receive connections in).

For example:

> On 17 Sep 2017, at 23:13, Scott Bennett <bennett at sdf.org> wrote:
> 
> Roger Dingledine <arma at mit.edu> wrote:
> 
>> On Sat, Sep 16, 2017 at 11:44:41PM +0000, dawuud wrote:
>>>> Your only option would be to ask your ISP to uncensor the internet,
>>>> unfortunately. Tor requires that all relays are able to contact all
>>>> other relays, and those which cannot participate in the network.
>>> 
>>> I think you meant to say:
>>> "Tor requires that all relays are able to contact all directory authorities"
>> 
>> Actually, no, we want it to be the case that all relays can reach all
> 
>     That does not contradict what dawuud wrote, as can be clearly seen.
> What you want and what tor currently requires are not the same thing at all.
> 
>> relays. The less true that becomes -- that is, the less clique-like
>> the network topology becomes -- the more complicated the anonymity
>> measurements become, and that is potentially quite bad.
> 
>     That is why OutboundBindAddress values need to be published somewhere.

Some relay operators don't want to publish all their IP addresses.
Other relay operators don't know or don't control their outbound addresses,
or have multiple outbound addresses.

Tor 0.2.7 used to publish OutboundBindAddresses in the exit policy by
default. But as of 0.2.9 this was considered a bug and split into
ExitPolicyRejectPrivate (which rejects published addresses) and
ExitPolicyRejectLocalInterfaces (which rejects other addresses).

So you could advocate for the adoption of ExitPolicyRejectLocalInterfaces 1,
and then scrape exit policies for these addresses.

Even then, you won't catch NATs and other weird arrangements that aren't
on the local machine.

> Those of us who use packet filters in defense of our systems and/or our LANs
> can allow connections to our relays' ORPorts from otherwise blocked addresses
> if we know which of those blocked addresses have tor relays that may be trying
> to connect.  Without that information, the only way you will ever get what you
> want is by turning away volunteers.

... or by asking volunteers not to hurt client anonymity by blocking
inbound connections. And telling them we might remove their relay in
future if they block too many other relays.

If you want to run a tor relay, it needs to be able to accept inbound
connections from any address. That's the best way to make sure tor
users are safe.

We need to keep doing this, until we get some good research on anonymity
in partially-connected networks.

T
--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20170918/97fe1bb5/attachment.sig>


More information about the tor-relays mailing list