unflagged BAD EXIT nodes
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 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVluDYAAoJEFv7XvVCELh0Y88P/2gUhDaks65Gg6664RrOOA5S T7UJzoJm392D1LK53gfmgKDf57QtsFr+52Ty6dHHrCrbqCiw4GutxGpVAjNtUjmb x1BuGHpCs/24t+Nn0dKfxGKjYfD8TtlA0CApUitcHwqCRATuFpEopeG02fRT7dBo k11Q+0YUzmg0TOhGzkWvP6zNW0iO2ziSniAv0U6AyXgDWgyelzNf39DP1QCpWwxa XXK+UMSthwhuZtWP9yQfaVBjTzkNUaUs1demqwUBsAZD+JuoqvCs7fKjVKrZfvmb YCfqiUKb3BojiWF5dWnxBm3K2Fuy91df2kLZkDkNobOd/nSQpQaDzqhOkJQ5gOxC VJAN9XoH5n1Fdg1g5g8fRTuSO9/kgN4P67GApS52VTHuFEqk3BSl8G1pBiH2nWos Iqi882i+MUq/xwBCDTrPQLuWHmdBhfSvYhvTbHZDQOubGhpt4+kqGoKqq7/E19UX tYTNWx3+PWTa9xkvbUWigCUzuDkHMJiVyZGNedpIwX9UjpalY2guJM6m0Enccgzw 9ypN9LtghcwPzNWC7R/FZDF80TJh1r/6aiyDbeZKE6QPZbMh67VaQ+ohnDSuFpuW 7CLayZ9MqJDc26dD95InCFUelCkWzZ7abSO4dmfGtJomoaL8LMRRVsYioi35R1z1 GdWzl1TN0Js+sZhR7DFR =5XtL -----END PGP SIGNATURE-----
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). -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVl5N1AAoJEFv7XvVCELh03cIP/jgiCrg+YaUjtUv6GHv4dkA9 PF40d4HIDQ7XBeMTFezHC/m7xFUeF163vG1zE2I5sWKD3UFXEOaAgXF+GMC8YpSs 83P2ewv8Mc5oNHwnyK5J0hjnaksix1b/X+C0GG+YJ8QixBGqZQ+wBHaBpr7DWsrx bDlcOJB1tyUKl6wRiZWPEGWCJBVMb4CSLzBA3bRVwt6kJXAalC2UQmcmRs+iCj1l 5IUHTbhAl/uc2dLlUx4LeXooZCL6zolHO4u2/dYdzTpOjVVBOx0E6e9EMO3YC25i 5fTaJRWq2V+Va3yfhIQWTQPAkEglbtxfThPidUaKTiWP6j3/70eYSoz5gdM3KwO5 Tm2PCuzgaLRsqd+tqBWnr0EXq5R/TQWsreYpbXwH5SpRUyGg/COELh8wRvYvRiUp +S/N1S38RwjV1I0cMyZvnDS5AFbqv6Jp9KzqyXFSGlS6mH2iJfDCH3211OjLbcpA XpqRzLrqTB4UELqbQkldqIS/aYqTxEb5L3PS4ZlzQG0BdGmYj8z1iI4r2BGjgjjD Zgx7TE2HNkwfgOp/0Lk067FgHcGaGRZMd+kF/KOn7+Yv25Lx9U7dQkd0EYRzT1og OrIloqAlHJgSLzsWrYZMRK7qVqQ/jyvfv/pXHmXUpqM3rFfozh1p4qjHuFZO9tx5 SknFJ0iiinZ+exe48ttc =0WMo -----END PGP SIGNATURE-----
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...
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.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.org<mailto: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.org<mailto: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, -- Yawning Angel [0]: Yes, the paper is old. It's the precursor research to ICE used by WebRTC.
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
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]
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/
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.
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. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVmG28AAoJEFv7XvVCELh01eQQAJyfe1Z95Hpg3t10Ov+eybnE 1koHUYj/gxEHDrtGAx/qvNet8i2RiZkrj+jorDUz3kw521GDEl2bbgo8tyyebBb3 Ixpf6ehiWH790cDvED2mLVZH28WAAh48Y/pLz88W6ut0yG5hpy/WqRnlaqJgv3Us TWk7HEOyxbDk0DGqbpdI8IoQUDQzz8gKiFn1SgrngJm++Gtg1e2oqYvjindK9EiY EaV8QObXjYLrud3ebCxkEx7kKM0plPbEbv1pOx9AudH4xElpty19R4Z+O7WSCcJP 4HtYUiiVQOy4C9PtItE7jA7PHT6j9P64UT1zqNhPG3sBRQQn8ENjR5U+OP5O/aG6 UUPkWNoVu6gZwXPH+3RFwkQO+3LgGEWXwRSh+s1k29DUDR10hPV+GmeTq3kKOObA ACn9f+6TM0NLqATocLrOZXB6qP9L8HNyax+x2QpppQlH2//Nylp1WyHps3U4KOCz Rma4xfJ/r/R+zfAU1X1YreLS4EMLBk/KBilxxV7Zal9R0Bki/LchKeFWRfNLyNcK 7dHiTVgSLs+Cff+TYd9MWFmPXvLpyqn0Ynn+KSYX5BYVL6uPfZ8/apl3cqUHQMZ0 MO+fmgUwBrvEIIEKOwJRH4RFeC0yj3M0BJdGrPxBCAg5woe8SNyYt39cL6rNCcbu 5QO7R84w1Trh5ivSvtRl =C5Uw -----END PGP SIGNATURE-----
participants (7)
-
Ben Serebin -
Damian Busby -
Damian Johnson -
Mirimir -
nusenu -
starlight.2015q2＠binnacle.cx -
Yawning Angel