[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-relays] Malicious Tor relays - post-analysis after two months

On 10/3/20 6:38 AM, nusenu wrote:
>> Me and several tor relay operator friends have questions about
>> Malicious Tor exit nodes. How do you define a node as malicious ?
> 
> In the particular case (at least the initial detection): Traffic manipulation at the exit relays.
> 
>> How bad is the situation now ?
> 
> This group [1] is still rather active and at this point they run a 3 digit number
> of relays, but it is not the only malicious group that is active on the Tor network and
> might not even be the group I worry about the most.
> 
> [1] https://medium.com/@nusenu/how-malicious-tor-relays-are-exploiting-users-in-2020-part-i-1097575c0cac
> 
>> Is there any other risk than ssl
>> striping ?
> 
> I think so, yes.
> The good thing about ssl-stripping attacks is, that it is easy
> to protect against and easy to detect (if you are aware). The catch is that
> most users are probably not aware.
> So when compared with all other types of attacks that malicious relays can perform,
> ssl-stripping is probably not the biggest worry.
> 
>> After the long
>> discussion on the tor relay mailing list, what will be implemented as
>> a solution ?
> 
> As far as I can see, nothing will change/be implemented in the near future
> at the Torproject or Tor directory authority level.
> 
> for Roger's (long term) plan see:
> https://gitlab.torproject.org/tpo/metrics/relay-search/-/issues/40001
> linked from
> https://blog.torproject.org/bad-exit-relays-may-june-2020
> 
> 
>> * is there / will there be things
>> implemented as a conclusion of the "call for support for proposal to
>> limit large scale attacks" ?
> 
> Nothing came out of that thread.
> 
>> * has it been possible to prepare / set
>> up precautions to avoid this king of situation
> 
> I don't think anything has been implemented to prevent or reduce the risk of this from reoccurring.

Unfortunately, our OODA loops[1] on all development and funding actions
are devastatingly, catastrophically long. This is due in part to slow
funding cycles, and in part due to an internal debate over Agile vs
Waterfall methodology[2]. I am in the Agile camp. I believe that Agile
will help us respond to things like this in hours, days, or at most
weeks, rather than months and years. Agile is how I ran the Tor Browser
development.

We just signed a funding proposal that covers "network health", which in
theory covers network scanning to find and respond to problems like
this. However, the funding is scoped to scalability and performance
work. It will be a little bit of a stretch to cover this type of exit
scanning too, but at least we will have Tor Project staff allocated to
this kind of work now.

The proposal took 18 months of background planning from us, ~6 months of
background research from me, and a couple months of proposal review,
with one revision round. Because of these issues on both sides, it has
literally been years since we identified this problem area, and got
funding to act on it.

The good news is we start Monday.


1. https://en.wikipedia.org/wiki/OODA_loop

2. https://www.seguetech.com/waterfall-vs-agile-methodology/

-- 
Mike Perry

Attachment: signature.asc
Description: OpenPGP digital signature

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