Re: [tor-relays] DoS attacks on multiple relays

["x9p" <tor@xxxxxxx>]

> On 8 Dec 2017, at 19:25, "teor" <teor2345@xxxxxxxxx> wrote:

> There's no evidence these guards are malicious. They might just be run
> by an operator who doesn't know to set ContactInfo and MyFamily.
> (And MyFamily is irrelevant for relays in a /16, anyway.)

Agree. There are good indicators, not evidence. Thats why I said to not
block those, but do so if you feel better safe than sorry.

> We are working on vanguards in 0.3.3 to address onion service guard
> discovery issues like this. That way, we change the entire network so
> onion services are safer. Changing just a few makes them stick out.

Nice to hear that! Nothing against the big boys collecting stuff to
correlate later, but if they really want to do so, at least have some hard
work integrating different cloud providers APIs to setup their servers.

> By "private guards" do you mean "bridges"?
> That would be a very bad idea: it would make the bridge and its onion
> services stand out within minutes or hours on the network, because
> each circuit gets a different middle node, and the nodes would not
> be evenly distributed.

Sorry, I meant EntryNodes

> If you block a guards on an onion service, it will look different, but
> that
> might be unnoticeable for a few months. (More precisely, it's safe in
> proportion the guard rotation period, divided by the number of related
> onion services blocking those guards, divided by the consensus weight
> fraction of blocked guards. We don't expect that people will do this
> calculation themselves, which is why we say "don't do that".)

Would it be a better approach than firewall blocking, setting
"ExcludeNodes + StrictNodes" with the offending/suspicious fingerprints?

> But we really don't recommend people block guards or set EntryNodes
> on an onion service. It's quite risky long-term.

Disagree about not setting EntryNodes, but agree EntryNodes shouldn't be
long-term. They should be rotated from time to time, different providers.

>
> T
>

cheers.

x9p



_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays