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

[Mike Perry]

On 10/5/20 9:15 AM, Georg Koppen wrote:
> Mike Perry:
>> 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.
> 
> If one has folks working on the topic, maybe. But that was and is not
> the problem here. We did not have a bunch of engineers who messed up
> their Waterfall model. We had and still don't have (as of me writing
> this mail) anyone being assigned to work on that.
> 
> So, Agile or whatever would not have helped us in that scenario.

The waterfall-style RFP is exactly why it took two years between our
discussions of the need for network health work, and our ability to
allocate staff to it.

To do the conception, initiation, analysis, and design, the performance
proposal probably cost the organization somewhere between $150k-$250k,
if we did a full accounting. We also relied heavily on volunteer
expertise and input.

This debate has happened many times in many industries. Here is another
example:
https://omgrfp.wordpress.com/category/omgrfp/

The Agile world is anti-dogmatic. There is no one true Agile. Here is a
model that proposes breaking up the RFP phase into an Agile/Lean style
discovery contract and main contract, to accommodate waterfall-style RFPs:
https://www.agilebuddha.com/agile/agile-for-fixed-bid-projects/

With an Agile/Lean discovery contract, we would have had resources to
perform some prototype discovery of the scope of the network scanning
problem, and (re)ran some preliminary MVP scans ourselves. Instead, we
had to shoot from the hip and wait. Meanwhile, evidence of the exit
problem's severity was not actionable by us, due to related org and
community issues of overwork and stress.

That Agile/Lean model for contracts parallels the Agile model for
development, as previously linked:
https://www.seguetech.com/waterfall-vs-agile-methodology/

On Monday, we agreed to run the development of the performance contract
in a more Agile way. Unfortunately, we still have to wind down the final
deployment phases of other projects before we can spin up network
health. We planned for this in the performance proposal timeline, but
that doesn't make it suck any less, given the reality of the situation.


Nusenu: please accept my apologies, even if the org and community will
not apologize. I believe I understand your frustration and your reaction
to us.

I was once in a very similar situation. As a volunteer, I wrote the
first Tor exit scanner back in ~2007. Back then, HD Moore made a
metasploit module called Torment that got widely used to deanonymize Tor
users using plugins and outside-browser proxy bypass. This was also why
I took over maintaining Torbutton, to update it to disable such proxy
bypass avenues. We ended up getting funding for Tor Browser, but never
exit scanning. Exit scanning has, to this day, been the work of
volunteers or something that paid staff have done time to time, after hours.

Anyway, thank you for you help! I will do my best to get people to pay
attention to your work while we unfuck ourselves.

In the meantime, please keep scanning!

Thank you, again.

-- 
Mike Perry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20201006/468bbb07/attachment.sig>