[metrics-team] Report on protecting Tor from Sybil attacks

[Philipp Winter]

Thanks for your thoughts, nusenu.

On Sat, Feb 27, 2016 at 03:31:42PM +0000, nusenu wrote:
> > Sybils per se do not have to be malicious; a relay operator could 
> > simply have forgotten to configure her relays as a relay family. 
> > Such Sybils are no threat to the Tor network
> 
> That implies to some extend that the MyFamily setting is useless as it
> makes no difference if set or not.
> 
> I would argue that even non-actively malicious "undeclared families" are
> a risk to tor clients because opsec failures will likely affect all
> relays in that undeclared family. If the operator's client gets
> compromised the odds are high that all relays fall with it. Operators of
> non properly configured families are therefore a more valuable target
> for malicious entities than an operator with a proper MyFamily
> configuration.

Right, I will add a clarifying sentence.

> Another question that comes up is: How do you tell benign Sybils apart
> from non-benign Sybils?

That's not always possible.  Most of the malicious ones we caught were
tampering with exit traffic or with the DHT.

> > Our modules ran [...] and discovered 251 malicious exit relays, shown
> > in Appendix A
> 
> Appendix A and table 4 do not "show" any relay information (like
> fingerprints)
> 
> I was also not able to find them at
> https://nymity.ch/sybilhunting/
> or in
> https://nymity.ch/sybilhunting/sybil-groups.tar.bz2
> (i.e. there is no 2014-08 folder/file)

Yes, we only provide an attack summary.  I will rephrase that.

> > Table 2: The Sybil groups 
> 
> Cross-checking with some OrNetRadar [1] emails:
> 
> Jan 2016 cloudvps family size: 61 vs 97
> http://article.gmane.org/gmane.network.onion-routing.ornetradar/854
> (if we ignore non-running relays, up=0, then the counts match)

The numbers in Table 2 are the total number of fingerprints we have
observed.

> Does sybilhunter take relays without valid flags into account?
> Onionoo does (and should continue to do so) - which could explain the
> difference.

Sybilhunter generally considers relays without the valid flag.

> What is your "observation window size" for churn based detection?
> In Figure 10 you mention 1h, 12h and 24h "smoothing window sizes".

The window size in the published data is one, so it can easily be
smoothed.

> cloudvps (125 relays, 2015-12-30) - not in list?
> http://article.gmane.org/gmane.network.onion-routing.ornetradar/816

There are many groups that we did not include in the table because we
are limited by space.

> > Figure 4
> 
> Are there plans to add such graphs to metrics?
> https://trac.torproject.org/projects/tor/ticket/15594
> 
> or is that part of
> https://lists.torproject.org/pipermail/metrics-team/2016-January/000060.html

Yes, I would like to add the churn rate and the uptime visualisation to
metrics.  I currently don't have much time to work on this, so there's
no ETA.  I didn't file this ticket.

> > Once all sequences are sorted, we color adjacent sequences in red if
> > their uptime sequence is identical.
> 
> from Dec 2015:
> "Right, I don't use perfect matching, so we can account for some noise"
> 
> https://lists.torproject.org/pipermail/tor-dev/2015-December/010042.html

We changed that.  The phrasing in the paper is correct.

> > [...] by eight distributed directory authorities [...]
> > [...] the nine directory authorities vote [...]
> > The majority of directory authorities, i.e., five out of eight
> 
> 8... 9...
> how about 10 ;)
> moria1, gabelmoo, dannenberg, tor26, urras, maatuska, dizum, Faravahar,
> Tonga, longclaw

That's indeed a mistake, thanks for pointing it out.  The correct number
is nine.  Tonga is a bridge authority, not a directory authority.

Cheers,
Philipp