Hello,
This summer Nusenu shared his posts about malicious relays [1][2] and it was followed by many answers.
A very important is Roger's one [3] explaining that the malicious relays have been kicked out of the network and that any new one should be reported.
I was wondering if, with some distance with this summer situation / discussion : * new malicious relays have been reported in any way ? * vigilance / watchfulness is still needed ? if yes : * is there specific cases to share (e.g. nodes that block HTTPS on a site or redirect to HTTP ?) * any concern to have on other protocols that use SSL (imaps, smtps, ssh) ? * is there / will there be things implemented as a conclusion of the "call for support for proposal to limit large scale attacks" ? * has it been possible to prepare / set up precautions to avoid this king of situation or it is a too long shot for such a problem ?
These questions come with a lot of respect for the project, its teams and the work done. No critics, it is just made to update the knowloedge on the subject as these questions came back with other friends and relay operators.
And perhaps a last one, perhaps specific for Nusenu : how do you define a malicious relay ? Sorry but I did not get that precisely, moreover in big group analysis.
All answers will be read with care and gratitude !
--- Corl3ss 2042 5D39 E7C1 E657 025E A28F 937D 8A90 FCB0 E24A
[1] https://lists.torproject.org/pipermail/tor-relays/2020-July/018643.html [2] https://lists.torproject.org/pipermail/tor-relays/2020-August/018817.html [3] https://lists.torproject.org/pipermail/tor-relays/2020-August/018845.html
Vigilance is always needed and appreciated, both manual and automated.
Stripping encryption only works when there's a non encrypted port available, in the case of SMTPS / IMAPS / SSH it's not possible.
As for the other questions, I can't really answer them.
2020-09-28 21:00 GMT, Corl3ss corl3ss@corl3ss.com:
Hello,
This summer Nusenu shared his posts about malicious relays [1][2] and it was followed by many answers.
A very important is Roger's one [3] explaining that the malicious relays have been kicked out of the network and that any new one should be reported.
I was wondering if, with some distance with this summer situation / discussion :
- new malicious relays have been reported in any way ?
- vigilance / watchfulness is still needed ? if yes :
- is there specific cases to share (e.g. nodes that block HTTPS on a site
or redirect to HTTP ?)
- any concern to have on other protocols that use SSL (imaps, smtps, ssh)
?
- is there / will there be things implemented as a conclusion of the "call
for support for proposal to limit large scale attacks" ?
- has it been possible to prepare / set up precautions to avoid this king of
situation or it is a too long shot for such a problem ?
These questions come with a lot of respect for the project, its teams and the work done. No critics, it is just made to update the knowloedge on the subject as these questions came back with other friends and relay operators.
And perhaps a last one, perhaps specific for Nusenu : how do you define a malicious relay ? Sorry but I did not get that precisely, moreover in big group analysis.
All answers will be read with care and gratitude !
Corl3ss 2042 5D39 E7C1 E657 025E A28F 937D 8A90 FCB0 E24A
[1] https://lists.torproject.org/pipermail/tor-relays/2020-July/018643.html [2] https://lists.torproject.org/pipermail/tor-relays/2020-August/018817.html [3] https://lists.torproject.org/pipermail/tor-relays/2020-August/018845.html
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-...
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.
kind regards, nusenu
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-...
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:
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-...
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.
Georg
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-...
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.
Corl3ss:
Hello,
This summer Nusenu shared his posts about malicious relays [1][2] and it was followed by many answers.
A very important is Roger's one [3] explaining that the malicious relays have been kicked out of the network and that any new one should be reported.
I was wondering if, with some distance with this summer situation / discussion :
- new malicious relays have been reported in any way ?
Yes, there have been more malicious relays reported. Some of them doing attacks like Roger mentioned. We kicked out all of those. There were other reports about relays that seem to belong to the group(s) we kicked out earlier this year.[1] Some of those relay groups have been kicked out, too.
- vigilance / watchfulness is still needed ? if yes :
- is there specific cases to share (e.g. nodes that block HTTPS on a site or redirect to HTTP ?)
- any concern to have on other protocols that use SSL (imaps, smtps, ssh) ?
Yes, there is still vigilance needed. While we have some scanners and some manual work is done, that's not enough, in particular against more sophisticated attackers.
- is there / will there be things implemented as a conclusion of the "call for support for proposal to limit large scale attacks" ?
We have some ideas on how to move forward which have different trade-offs and we realized that a lot of them touch the question of what we want the Tor network to be in the future. I had hoped that I would have sent an email about that by now to this list asking the community about input and possible options but alas it's still sitting unfinished in my drafts folder. :(
- has it been possible to prepare / set up precautions to avoid this king of situation or it is a too long shot for such a problem ?
We don't have good ways to fix this problem in the short term. So, until we make progress on any of our longer term plans we somehow need to keep up with the whack-a-mole game we have been playing for quite some time now.
These questions come with a lot of respect for the project, its teams and the work done. No critics, it is just made to update the knowloedge on the subject as these questions came back with other friends and relay operators.
No worries, I am happy to take criticism of the status quo and our future plans. :)
And perhaps a last one, perhaps specific for Nusenu : how do you define a malicious relay ? Sorry but I did not get that precisely, moreover in big group analysis.
That's a good question. I am not Nusenu and will thus defer the answer to them. But it's a good question to think about regardless as finding a good answer to it is part of the problem of removing bad relays. Kicking out relays that got caught while doing e.g. SSL stripping attacks is easy but what about a group of relays with similar (and what is "similar"?) configuration showing up like on the next day or days thereafter? Is that the some entity just joining the network again to be able to launch new attacks at *some* point? Or is it some new contributor that likes to help the network growing/diversifying? And what about all those relays without a valid ContactInfo? Are those anonymous contributors that want to help the Tor network or sneaky attackers? Etc.
This touches the question of what we want the Tor network to be (and how we would manage trust relationships in it), too...
All answers will be read with care and gratitude !
Thanks and thanks for your questions, Georg
[1] https://blog.torproject.org/bad-exit-relays-may-june-2020
On 2020-10-07 7:24 a.m., Georg Koppen wrote:
Corl3ss:
Hello,
This summer Nusenu shared his posts about malicious relays [1][2] and it was followed by many answers.
A very important is Roger's one [3] explaining that the malicious relays have been kicked out of the network and that any new one should be reported.
I was wondering if, with some distance with this summer situation / discussion :
- new malicious relays have been reported in any way ?
Yes, there have been more malicious relays reported. Some of them doing attacks like Roger mentioned. We kicked out all of those. There were other reports about relays that seem to belong to the group(s) we kicked out earlier this year.[1] Some of those relay groups have been kicked out, too.
- vigilance / watchfulness is still needed ? if yes :
- is there specific cases to share (e.g. nodes that block HTTPS on a site or redirect to HTTP ?)
- any concern to have on other protocols that use SSL (imaps, smtps, ssh) ?
Yes, there is still vigilance needed. While we have some scanners and some manual work is done, that's not enough, in particular against more sophisticated attackers.
- is there / will there be things implemented as a conclusion of the "call for support for proposal to limit large scale attacks" ?
We have some ideas on how to move forward which have different trade-offs and we realized that a lot of them touch the question of what we want the Tor network to be in the future. I had hoped that I would have sent an email about that by now to this list asking the community about input and possible options but alas it's still sitting unfinished in my drafts folder. :(
- has it been possible to prepare / set up precautions to avoid this king of situation or it is a too long shot for such a problem ?
We don't have good ways to fix this problem in the short term. So, until we make progress on any of our longer term plans we somehow need to keep up with the whack-a-mole game we have been playing for quite some time now.
These questions come with a lot of respect for the project, its teams and the work done. No critics, it is just made to update the knowloedge on the subject as these questions came back with other friends and relay operators.
No worries, I am happy to take criticism of the status quo and our future plans. :)
And perhaps a last one, perhaps specific for Nusenu : how do you define a malicious relay ? Sorry but I did not get that precisely, moreover in big group analysis.
That's a good question. I am not Nusenu and will thus defer the answer to them. But it's a good question to think about regardless as finding a good answer to it is part of the problem of removing bad relays. Kicking out relays that got caught while doing e.g. SSL stripping attacks is easy but what about a group of relays with similar (and what is "similar"?) configuration showing up like on the next day or days thereafter? Is that the some entity just joining the network again to be able to launch new attacks at *some* point? Or is it some new contributor that likes to help the network growing/diversifying? And what about all those relays without a valid ContactInfo? Are those anonymous contributors that want to help the Tor network or sneaky attackers? Etc.
This touches the question of what we want the Tor network to be (and how we would manage trust relationships in it), too...
All answers will be read with care and gratitude !
Thanks and thanks for your questions, Georg
[1] https://blog.torproject.org/bad-exit-relays-may-june-2020
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Is there a way that some Tor users can help identify malicious relays? Perhaps run a 'scanner' or other software utilizing the users' unused bandwidth.
I for one would be willing to offer such help.
G
tor-relays@lists.torproject.org
-
Corl3ss -
G -
Georg Koppen -
Mike Perry -
nusenu -
William Kane