Re: [tor-relays] Blog: How Malicious Tor Relays are Exploiting Users in 2020 (Part I)

[William Kane <ttallink@xxxxxxxxxxxxxx>]

I knew about this issue years ago, but there's not much I can do to
mitigate it except for spinning up more, legit Tor exit instances to
try and limit the probability of an attack happening to a user.

We need way more legitimate relays, and not just on OVH, Hetzner and
Online's up streams which are likely already wiretapped due to being
the biggest entities hosting the majority of relays.

Possibly start some campaign to get people to run Tor relays as long
as they match some criteria (not on dynamic lines, not on hosters that
are already crowded with relays, etc.).

I was trying to get my tech-savvy friends to run Tor relays, but most
of them are not interested - the problem with abuse that exit
operators frequently encounter scares most of them off and they just
lose interest in running any kind of relay completely -. sadly, the
public image of Tor is just that bad - blame the media networks for
that..

I don't think monetary incentives would be feasible, but there has to
be something that we can do to get people to smarten up and run more
relays on unpopular hosters.

In the future I'd like to see at least 50000 relays of all types, and
out of those, at least 15000 exit relays spread out on many different
up streams / data-centers, ran by legitimate businesses or private
entities, to minimize chances of timing correlation and similar
attacks.

Stuff like sslstrip should be addressed in the client code for the Tor
Browser, and it should be really easy to implement.

2020-08-14 20:48 GMT, Georg Koppen <gk@xxxxxxxxxxxxxx>:
> Igor Mitrofanov:
>> Is there anything Tor can do inside the Tor browser itself?
>> I would understand and support something as drastic as disabling
>> non-HTTPS,
>> non-Onion connections altogether. When the user types a URL with no
>> protocol prefix, the browser will assume HTTPS.
>> This may break some websites, so a transition may be required. Such a
>> transition can start with a warning banner, proceed to a warning page,
>> then
>> to a browser setting to enable it, and finally to disabling the
>> capability
>> for good.
>>
>> The above assumes there is much less benefit in running a rogue Tor exit
>> if
>> the operator cannot see or alter the content it is relaying.
>
> I think that assumption is not unreasonable. Yes, we are actively
> thinking about trying an HTTPS-only mode out as part of a defense
> against similar attacks. See the blog post[1] about it which we just
> published, which should give more context for the incident as well.
>
> Georg
>
> [1] https://blog.torproject.org/bad-exit-relays-may-june-2020
>
>> On Fri, Aug 14, 2020 at 1:25 PM niftybunny <
>> abuse-contact@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>>
>>>
>>> https://medium.com/@nusenu/how-malicious-tor-relays-are-exploiting-users-in-2020-part-i-1097575c0cac
>>>
>>>
>>>    - There are multiple indicators that suggest that the attacker still
>>>    runs >10% of the Tor network exit capacity (as of 2020–08–08)
>>>
>>>
>>> And on this one: I trust nusenu who told me we still have massiv
>>> malicious
>>> relays.
>>>
>>>
>>>
>>> On 14. Aug 2020, at 19:12, Roger Dingledine <arma@xxxxxxxxxxxxxx> wrote:
>>>
>>> On Thu, Aug 13, 2020 at 03:34:55PM +0200, niftybunny wrote:
>>>
>>> This shit has to stop. Why are the relays in question still online?
>>>
>>>
>>> Hm? The relays are not online -- we kicked them in mid June.
>>>
>>> We don't know of any relays right now that are attacking users.
>>>
>>> Or said another way, if anybody knows of relays that are doing any
>>> attacks
>>> on Tor users, ssl stripping or otherwise, please report them. I believe
>>> that we are up to date and have responded to all reports.
>>>
>>> That said, there is definitely the uncertainty of "I wonder if those
>>> OVH relays are attacking users -- they are run by people I don't know,
>>> though there is no evidence that they are." We learned from this case
>>> that making people list and answer an email address didn't slow them
>>> down.
>>>
>>> I still think that long term the answer is that we need to shift the
>>> Tor network toward a group of relay operators that know each other --
>>> transparency, community, relationships, all of those things that are
>>> costly to do but also costly to attack:
>>> https://gitlab.torproject.org/tpo/metrics/relay-search/-/issues/40001
>>> https://lists.torproject.org/pipermail/tor-relays/2020-July/018656.html
>>> https://lists.torproject.org/pipermail/tor-relays/2020-July/018669.html
>>>
>>> But the short term answer is that nobody to my knowledge has shown us
>>> any current relays that are doing attacks.
>>>
>>> Hope that helps,
>>> --Roger
>>>
>>> _______________________________________________
>>> tor-relays mailing list
>>> tor-relays@xxxxxxxxxxxxxxxxxxxx
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>
>>>
>>> _______________________________________________
>>> tor-relays mailing list
>>> tor-relays@xxxxxxxxxxxxxxxxxxxx
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>
>>
>>
>> _______________________________________________
>> tor-relays mailing list
>> tor-relays@xxxxxxxxxxxxxxxxxxxx
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
>
>
>
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays