Could someone comment on why 15 exit nodes discovered to be sniffing and abusing login credentials have not been marked with the BAD EXIT flag?
The research appears to be legitimate, involved a good deal of effort, and seems credible:
https://chloe.re/2015/06/20/a-month-with-badonions/
was blogged by Sophos, also credible
https://nakedsecurity.sophos.com/2015/06/25/can-you-trust-tors-exit-nodes/
Is there an issue of trust w/r/t this security researcher? An issue of methodology and/or reproducibility? A shortage of resources to follow up? An investigation attempting to identify the operators?
The researcher writes that they received a polite reply from and was summarily ignored with no further comment. AND the exits continue to steal and abuse credentials. If true this would be contrary to the inclusiveness generally exhibited by the Tor Project.
IMO a likely password-stealing exit should be marked-first, questions asked later. If some kind of mix-up or mistake has occurred, a good operator should readily be able to defend themselves and not feel ruffled for it.
Looking through the list of suspect exit nodes, they fall into three categories:
1) very low-bandwidth Window Vista systems running 0.2.4.21
2) recently dead/offline
3) one massive Linux exit
The (1) exits might be hacked Windows systems, perhaps part of a botnet --no contact given. Seems an easy call to mark them BAD.
The (2)s are probably offline (1)s and so deserve to be marked BAD as they may return.
The highly-ranked (3) with 20MB/sec is only three months old and does not provide contact information, resides in the Ukraine. Also an easy call if you ask me: BAD EXIT.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
you can find answers to some of your questions here: https://lists.torproject.org/pipermail/tor-talk/2015-June/038264.html
On 07/03/2015 01:22 PM, nusenu wrote:
you can find answers to some of your questions here: https://lists.torproject.org/pipermail/tor-talk/2015-June/038264.html _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
But bottom line, the Tor Project apparently did nothing with the information. Or if it did, I haven't seen anything about it.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
But bottom line, the Tor Project apparently did nothing with the information.
Well, they apparently made (according to phw) an informed decision on which attacks they should be spending the little available resources. That is certainly more than doing 'nothing'.
Philipp Winter explained the general situation quite clearly (without going into the specifics of the reported relays):
there are not enough people to keep up with all the work. The little resources we have we tend to spend on more serious attacks. That is not to say that traffic sniffing is harmless, but we are forced to prioritise
So if this does not match with ones assumptions and threat model it is probably good to adjust the threat model towards it. It is certainly better to always assume the presence of bad exits because it is impossible to detect them all, all the time, with no delay (and because even good exits have to route their packets through the "bad internet" to its final destination.)
I'm _not_ saying that we should forget about the 'badexit' flag altogether because "we can't get hold of all of them anyway", but now we know more about the resources of those managing badexit flags and its implications.
I find it more worrying that we do not "hear" about the 'more serious attacks' that keep them busy and don't allow them to look into i.e. 'AviatoChortler' (even after a few weeks). That might mean that there is a constant stream of 'more serious attacks' (without information I can only guess).
I find it more worrying that we do not "hear" about the 'more serious attacks' that keep them busy and don't allow them to look into i.e. 'AviatoChortler' (even after a few weeks). That might mean that there is a constant stream of 'more serious attacks' (without information I can only guess).
... or it could also be that we're simply spread too thin. ;)
Bad relay detection is a space that doesn't traditionally get much focus. Presently Philipp is the only person investing time here, and he both has a day job and would prefer to do more interesting things (like write code!) in his free time.
As I see it there's three areas that need to be improved in this space...
1. Bad relay detection. Philipp's ExitMap [1] and my naive sybil checker [2] are the only automated checks I'm aware of right now. That leaves a lot of room for improvement.
2. Openness. Traditionally there's been some contention about where to draw the line between openness and secrecy. Personally this is what turned me off to this space [3]. Thankfully Philipp's moving us toward being a little less secretive. [4]
3. Responsiveness. To get a relay flagged we need to persuade directory authority operators to manually intervene by editing their torrc. I get the impression all the dirauths that vote on BadExit now use Philipp's git repository so hopefully this is better than it once was.
All this is to say 'help welcome!'. If this is a space you truly care about then please make it better! Philipp can best say where more hands would be useful.
Cheers! -Damian
[1] http://www.cs.kau.se/philwint/spoiled_onions/ [2] https://gitweb.torproject.org/doctor.git/tree/sybil_checker.py [3] see the 'As of April 2013 this list is no longer being maintained' note on https://trac.torproject.org/projects/tor/wiki/doc/badRelays [4] https://trac.torproject.org/projects/tor/ticket/13302
Sorry for hijacking, but I wasn't sure where best to put this.
As a programmer, where should I start if I am considering lending my time to the tor project? While I feel that the BAD EXIT issue needs some love, I defer to those with more knowledge on the state of things to direct my efforts.
Is there a online resource I should peruse, or is it more of a secret society complete with hazing and chanting?
Once again, sorry for the interruption.
The Other Damian
On Sat, Jul 4, 2015, 12:12 PM Damian Johnson atagar@torproject.org wrote:
I find it more worrying that we do not "hear" about the 'more serious attacks' that keep them busy and don't allow them to look into i.e. 'AviatoChortler' (even after a few weeks). That might mean that there is a constant stream of 'more serious attacks' (without information I can only guess).
... or it could also be that we're simply spread too thin. ;)
Bad relay detection is a space that doesn't traditionally get much focus. Presently Philipp is the only person investing time here, and he both has a day job and would prefer to do more interesting things (like write code!) in his free time.
As I see it there's three areas that need to be improved in this space...
- Bad relay detection. Philipp's ExitMap [1] and my naive sybil
checker [2] are the only automated checks I'm aware of right now. That leaves a lot of room for improvement.
- Openness. Traditionally there's been some contention about where to
draw the line between openness and secrecy. Personally this is what turned me off to this space [3]. Thankfully Philipp's moving us toward being a little less secretive. [4]
- Responsiveness. To get a relay flagged we need to persuade
directory authority operators to manually intervene by editing their torrc. I get the impression all the dirauths that vote on BadExit now use Philipp's git repository so hopefully this is better than it once was.
All this is to say 'help welcome!'. If this is a space you truly care about then please make it better! Philipp can best say where more hands would be useful.
Cheers! -Damian
[1] http://www.cs.kau.se/philwint/spoiled_onions/ [2] https://gitweb.torproject.org/doctor.git/tree/sybil_checker.py [3] see the 'As of April 2013 this list is no longer being maintained' note on https://trac.torproject.org/projects/tor/wiki/doc/badRelays [4] https://trac.torproject.org/projects/tor/ticket/13302 _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
I'll hijack the response.... I'm a sysadmin, an unloved Windows one. My unwanted $0.02 are:
- Windows installer (omg, Windows, the evil one which if you really want greater adoption is the answer! Oh smokes, someone said it!
- change the architecture so running behind nat works (this is probably the #1 limit factor for increasing relays). Every tom, dick, and harry could then add bandwidth via every internet circuit. It would be insane!
-Ben
From: Damian Busby Sent: Saturday, July 4, 2015 7:21 PM To: tor-relays@lists.torproject.org Reply To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] unflagged BAD EXIT nodes
Sorry for hijacking, but I wasn't sure where best to put this.
As a programmer, where should I start if I am considering lending my time to the tor project? While I feel that the BAD EXIT issue needs some love, I defer to those with more knowledge on the state of things to direct my efforts.
Is there a online resource I should peruse, or is it more of a secret society complete with hazing and chanting?
Once again, sorry for the interruption.
The Other Damian
On Sat, Jul 4, 2015, 12:12 PM Damian Johnson <atagar@torproject.orgmailto:atagar@torproject.org> wrote:
I find it more worrying that we do not "hear" about the 'more serious attacks' that keep them busy and don't allow them to look into i.e. 'AviatoChortler' (even after a few weeks). That might mean that there is a constant stream of 'more serious attacks' (without information I can only guess).
... or it could also be that we're simply spread too thin. ;)
Bad relay detection is a space that doesn't traditionally get much focus. Presently Philipp is the only person investing time here, and he both has a day job and would prefer to do more interesting things (like write code!) in his free time.
As I see it there's three areas that need to be improved in this space...
1. Bad relay detection. Philipp's ExitMap [1] and my naive sybil checker [2] are the only automated checks I'm aware of right now. That leaves a lot of room for improvement.
2. Openness. Traditionally there's been some contention about where to draw the line between openness and secrecy. Personally this is what turned me off to this space [3]. Thankfully Philipp's moving us toward being a little less secretive. [4]
3. Responsiveness. To get a relay flagged we need to persuade directory authority operators to manually intervene by editing their torrc. I get the impression all the dirauths that vote on BadExit now use Philipp's git repository so hopefully this is better than it once was.
All this is to say 'help welcome!'. If this is a space you truly care about then please make it better! Philipp can best say where more hands would be useful.
Cheers! -Damian
[1] http://www.cs.kau.se/philwint/spoiled_onions/ [2] https://gitweb.torproject.org/doctor.git/tree/sybil_checker.py [3] see the 'As of April 2013 this list is no longer being maintained' note on https://trac.torproject.org/projects/tor/wiki/doc/badRelays [4] https://trac.torproject.org/projects/tor/ticket/13302 _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.orgmailto:tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Sat, 4 Jul 2015 19:34:45 -0400 Ben Serebin ben@reefsolutions.com wrote:
I'll hijack the response.... I'm a sysadmin, an unloved Windows one. My unwanted $0.02 are:
- Windows installer (omg, Windows, the evil one which if you really
want greater adoption is the answer! Oh smokes, someone said it!
Ignoring this, not a platform I use or particularly care about, etc.
- change the architecture so running behind nat works (this is
probably the #1 limit factor for increasing relays). Every tom, dick, and harry could then add bandwidth via every internet circuit. It would be insane!
Running relays behind NATs does work, you either need to setup port forwarding manually or provide a tor-fw-helper executable, with the former being massively preferable.
"tor-fw-helper" isn't being distributed/built at all despite having had a portable rewrite (Check my github repo), instead of the C code that depends on a bunch of sketchy library code (included in the tor source tree), because:
a) A lot of uPnP/NAT-PMP implementations on the router side are utterly horrific, and will crash if you look at them funny.
b) Playing tech support for people that encounter "a" is not something I can personally do, and probably neither the support team.
c) A person that can't figure out port forwarding probably should not be running a relay in the first place.
An important thing to consider here is that, beyond bandwidth relay uptime and stability are also important considerations, which is not something usually obtainable from someone's home computer (eg: people turning it off at night).
If by this you mean, "make relays work from behind NATs without port forwarding in any shape or form" that's a far trickier prospect. It's important that every relay can talk to every other relay, and TCP NAT traversal when both boxes are behind NATs requires a intermediary of some sort (See: http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf for a reasonable intro to how this works[0]).
Regards,
Sorry for hijacking, but I wasn't sure where best to put this...
Glad you want to get involved! This would be more suited for its own thread on tor-dev@ but that said, my top suggestion is: pick something that interests you. Enjoying your involvement with open source and, by extension, sticking around to become a long term contributor is more important than any particular task. :)
Some good spots to get started are...
* Summary of our projects and points of contact: https://www.torproject.org/getinvolved/volunteer.html.en#Projects * Fun way to learn more about tor: https://media.torproject.org/video/
Cheers! -Damian
Thanks for all the useful links and directions.
We now return to our regularly scheduled program: "unflagged BAD EXIT nodes, and the women who love them".
The other Damian
On Sat, Jul 4, 2015 at 4:59 PM Damian Johnson atagar@torproject.org wrote:
Sorry for hijacking, but I wasn't sure where best to put this...
Glad you want to get involved! This would be more suited for its own thread on tor-dev@ but that said, my top suggestion is: pick something that interests you. Enjoying your involvement with open source and, by extension, sticking around to become a long term contributor is more important than any particular task. :)
Some good spots to get started are...
- Summary of our projects and points of contact:
https://www.torproject.org/getinvolved/volunteer.html.en#Projects
- Fun way to learn more about tor: https://media.torproject.org/video/
Cheers! -Damian _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
- Openness. Traditionally there's been some contention about where
to draw the line between openness and secrecy. Personally this is what turned me off to this space [3]. Thankfully Philipp's moving us toward being a little less secretive. [4]
thanks for the URL [4] https://trac.torproject.org/projects/tor/ticket/13302
really looking forward to see a non-empty https://gitweb.torproject.org/authdirbadexit.git/
- Responsiveness. To get a relay flagged we need to persuade
directory authority operators to manually intervene by editing their torrc. I get the impression all the dirauths that vote on BadExit now use Philipp's git repository so hopefully this is better than it once was.
And maybe bad-relay submissions could be published after a few weeks if you know, you will not have any time to look at the submission in the near future.
tor-relays@lists.torproject.org
-
Ben Serebin -
Damian Busby -
Damian Johnson -
Mirimir -
nusenu -
starlight.2015q2＠binnacle.cx -
Yawning Angel