Re: [tor-talk] State of bad relays (March 2017)

[Seth David Schoen]

nusenu writes:

> that put users at risk because they potentially see traffic entering
> _and_ leaving the tor network (which breaks the assumption that not
> every relay in a circuit is operated by the same operator).

(strictly speaking, the assumption that no more than one relay in a
circuit is operated by the same operator)

-- 
Seth Schoen  
Senior Staff Technologist   https://www.eff.org/
Electronic Frontier Foundation  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109   +1 415 436 9333 x107
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] State of bad relays (March 2017)

[nusenu]

Thanks for this email.

> Two common Tor network abuses are:
> 
> a) Bad exit nodes sniffing and messing around with client traffic.
> 
> b) Bad HSDir nodes. The hidden service hash ring is a particularly juicy
>target, since participating relays get to see the addresses of onion
>services when they publish their descriptors.

I hoped tor directory authorities would care [1] about tor relay groups
with end-to-end capabilities as much as about HSDirs.

https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dangerous_relaygroups.txt
(this list is truncated)

(even though they might not be intentionally malicious;
yes contactinfo can be arbitrarily forged)

I think an actual step to help protect tor users and to improve the
current situation is to implement proposal 242 (better families) [2]
followed by a stricter enforcement of it by dir auths (unlikely to happen).
Proposal 242 reduces the burden from tor relay ops when running more
than one relay and hopefully decreases the number of undeclared families
that put users at risk because they potentially see traffic entering
_and_ leaving the tor network (which breaks the assumption that not
every relay in a circuit is operated by the same operator).

Even with prop 242 available in a released tor version its usefulness
depends on the actual adoption by relay ops, something that is hard to
predict,
but implementing prop242 certainly scales better than contacting every
tor relay operator that does not set MyFamily (properly).

[1]
protecting users from known relay groups with end-to-end correlation
capabilities
https://lists.torproject.org/pipermail/tor-dev/2016-December/011714.html

[2]
https://gitweb.torproject.org/torspec.git/tree/proposals/242-better-families.txt
https://trac.torproject.org/projects/tor/ticket/5565



signature.asc
Description: OpenPGP digital signature
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] State of bad relays (March 2017)

[George Kadianakis]

Hello list,

in this email we will present you the current state of bad relays on the Tor 
network.

It should be no surprise that the Tor network is under constant attack. As part
of critical Internet infrastructure, people have been attacking our network in
various ways and for multiple reasons. Some people do it for research purposes,
others to satisfy their curiosity whereas others have flat out malicious intent.

Two common Tor network abuses are:

a) Bad exit nodes sniffing and messing around with client traffic.

b) Bad HSDir nodes. The hidden service hash ring is a particularly juicy
   target, since participating relays get to see the addresses of onion
   services when they publish their descriptors.
   
Both of those attacks require the adversary to setup relays on the network, and
this gives us a chance to catch and block them.

Our elite bad relay hunting team has been chasing down those bad actors and
blocking them from the network. Over the years, we've discovered hundreds of
evil relays that have been attacking the network. Here is a graph that shows
the volume of bad relays we've found over time:

   https://extra.torproject.org/misc/asn/authdir-2017-03-gray.png

The bottom part of the graph shows relays caught participating in exit node
attacks (see (a) above). And the top part of the graph shows relays that have
been conducting HSDir-related attacks (see (b) above) or other miscellaneous
attacks.

As you can see there is quite a number of relays participating in HSDir-related
attacks and finding them has been time consuming. However, the good news is
that these HSDir attacks will be addressed completely and forever when we roll
out Next Generation Hidden Services:

https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt

With Next Gen Hidden Services, HSDir relays won't be able to learn the
address of onion services anymore, because their descriptors will be
completely encrypted.

Anyway, this was an email to brief you up on our efforts of detecting bad
actors on the network and to let you know that we've got your back.

And don't forget to send your warmest thanks to the 1337 members of our bad
relay hunting team if you ever see them around the network :)

Have a good day!
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] blocking sinkholes and honeypots

[Jon Tullett]

On 28 February 2017 at 06:07, scar  wrote:
> I believe we should encourage
> sinkhole/honeypot operators to just block/ignore Tor exit IPs that connect
> to their traps.  what do you all think?

Wouldn't that risk giving away the fact that it's a honeypot?

-J
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk