January 2012 - tor-relays - lists.torproject.org

New authority
by Sebastian Urbach 10 Jan '12

10 Jan '12

Hi, freedompenguin v3 orport=9001 AC0AF18E61A3660B1F3BAC9FF9DF061D9E446735 May someone add the data to the add_default_trusted_dirservers() function in config.c, using the syntax "v3ident=<fingerprint>". Thanks. Btw. i respond pretty fast to server / network issues ;-) -- Mit freundlichen Grüßen / Yours sincerely Sebastian Urbach -------------------------------------------------------- Religion is something left over from the infancy of our intelligence, it will fade away as we adopt reason and science as our guidelines. -------------------------------------------------------- Bertrand Arthur William Russell (1872-1970), British philosopher, logician, mathematician, historian, and social critic.

1 0

Re: [tor-relays] not specified families
by Tor Relays at brwyatt.net 10 Jan '12

10 Jan '12

Wouldn't it be possible to code the Tor clients to not build circuits using relays in the same /24 or with "similar" names? While that wouldn't fix ALL possible attack scenarios, that could certainly help, and help against accidental (or malicious) misconfigured nodes. On Tue, 10 Jan 2012 00:28:16 +0100, "Aurel W." <aurel.w(a)gmail.com> wrote: >> Malicious relays trying to de-anonimize people are not going to use >> MyFamily for obvious reasons, and also they will not choose an obvious >> nick sequence like MetallicaFan1, MetallicaFan2,etc >> So it seems to me this option has only theoretical benefit, but in >> practice it's naive. > True, but in theory you also have to consider that nodes could get > compromised and then it is very likely that a whole family is affected > (may be too paranoid for some). > > I also wonder if it gets harder to identify a real threat, of a > malicious attacker operating many nodes, if there are so many other > cases of not-specified families. > > The "MetallicaFan1, MetallicaFan2,.." nodes might not be a problem, > because no one with a malicious attempt would name nodes like that. > But they are an indication, that there might be a bunch of other > nodes, without any such strong sings, but which are also operated by > one single individual. Because obviously, it's a very common mistake > in configuration. > > There might be feasible techniques to find suspicious groups of > relays, but with all this non specified families, this would be rather > pointless. > > aurel > > aurel > > On 9 January 2012 23:39, Javier Bassi <javierbassi(a)gmail.com> wrote: >> On Mon, Jan 9, 2012 at 7:13 PM, Aurel W. <aurel.w(a)gmail.com> wrote: >>> Shouldn't this be treated more seriously? There are literally over 100 >>> high bandwidth relays, which should specify a family but which don't. >>> If you monitor a client, it is very frequently that circuits are built >>> where two relays are clearly controlled by the same person. >>> >>> As a first try I mailed to two contact email addresses, but I haven't >>> got any response. >> >> In the end its the same. Relay operators who are willing to place >> MyFamily in their torrc file are not the ones that are going to try to >> identify you. >> Malicious relays trying to de-anonimize people are not going to use >> MyFamily for obvious reasons, and also they will not choose an obvious >> nick sequence like MetallicaFan1, MetallicaFan2,etc >> So it seems to me this option has only theoretical benefit, but in >> practice it's naive. >> Or maybe I'm missing something >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

Re: [tor-relays] not specified families
by Tor Relays at brwyatt.net 09 Jan '12

09 Jan '12

Probably just misconfigured. If there are emails attached to the nodes you could try mailing them directly about it. brwyatt On Fri, 6 Jan 2012 01:29:42 +0100, "Aurel W." <aurel.w(a)gmail.com> wrote: > Hi, > > when I browse through the list of relays I find many router names, > which correlate in some way, but which don't specify a family in their > descriptors. > > Just to name a few: > * 2* c5VycfOP > * 3* c516a > * Caldron, Caldron2, Caldron3 > * BlgTOR2, BlgTOR > * DwarfHappy, DwarfSleepy, DwarfSneezy, DwarfDopey > * DONATIONxTORx0 - DONATIONxTORx7 > and so on,... > > is there a reason, why there is such a high number of relays, which > fail to specify a family, since this seams rather striking? > > aurel > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

5 7

Re: [tor-relays] consensus update request
by Scott Bennett 09 Jan '12

09 Jan '12

Thanks, Sebastian, for the very quick reply. On Sun, 8 Jan 2012 15:12:25 +0100 Sebastian Hahn <mail(a)sebastianhahn.net> wrote: >On Jan 8, 2012, at 3:09 PM, Scott Bennett wrote: > >> The last consensus document expired about 15 hours ago. I understand >> that the authority operators and tor developers are probably occupied with >> fixing whatever is the trouble, but if someone in that group of individuals >> can spare a moment to fill us in on what is happening, I, for one, would >> greatly appreciate it. >> FWIW, I think a page on the torproject.org web site for very brief >> status updates on extraordinary situations like this one would be a good >> and helpful addition. >> Thanks much, and best of luck getting things working right again. > >People are indeed working to restore service. Currently it looks like Glad to know that. >two authorities are completely offline, and a couple others are too >overloaded to function properly wrt voting. Hmm. Will this situation, then, result in a renewed effort to find a few more people to run authorities? > >In the meantime you might like >https://metrics.torproject.org/consensus-health.html which monitors the >consensus. Thanks for that, too. It's not what I had in mind, but it is interesting, nonetheless. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

5 4

Internal server error while fetching from dizum
by Klaus Layer 09 Jan '12

09 Jan '12

Hi, my relays are getting 500 error while fetching data from authority dizum. Can someone explain what is happening with this tor authority? Regards, Klaus 14:25:51 [WARN] Received http status code 500 ("Internal Server Error") from server '194.109.206.212:80' while fetching "/tor/server/d/C539CB98343680892C46D0A70770E6D0A4A39564+E5A7994519731C2C3349AAA4C2A38CED2CE74457+E8507D31268490E9E4E8A2110E371F1537156C75+E8BCD670FFB8ADF73195BDB9362ACDDB28F704A5+E94B92087B4614CB7F1C9CC1191C383- 7D890C60E+EA71B375FC45F026C854C903887D981CF19B7326+EA9DE146A13B316D2F3D5C2ACF491C068B93FF9D+EB896E11C16C0531D83560D3CBBEF97AF2FFF4D5+ECEBAAF01CA177EEB68A8A6838E4A16- BD54749F6+ED5A60237FDCA188DF30DC380536754DFBF01404.z". I'll try again soon.

2 3

consensus update request
by Scott Bennett 08 Jan '12

08 Jan '12

The last consensus document expired about 15 hours ago. I understand that the authority operators and tor developers are probably occupied with fixing whatever is the trouble, but if someone in that group of individuals can spare a moment to fill us in on what is happening, I, for one, would greatly appreciate it. FWIW, I think a page on the torproject.org web site for very brief status updates on extraordinary situations like this one would be a good and helpful addition. Thanks much, and best of luck getting things working right again. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

2 1

Relay vs. bridge: difference in traffic?
by Steve Snyder 06 Jan '12

06 Jan '12

Can someone tell how being a bridge compares to being a regular exit node in terms of traffic? I can see how there would less traffic as a bridge since the node isn't advertised. On the other hand, there are many fewer bridges than regulat nodes so maybe the traffic on a given bridge is greater? Thanks.

2 1

not specified families
by Aurel W. 06 Jan '12

06 Jan '12

Hi, when I browse through the list of relays I find many router names, which correlate in some way, but which don't specify a family in their descriptors. Just to name a few: * 2* c5VycfOP * 3* c516a * Caldron, Caldron2, Caldron3 * BlgTOR2, BlgTOR * DwarfHappy, DwarfSleepy, DwarfSneezy, DwarfDopey * DONATIONxTORx0 - DONATIONxTORx7 and so on,... is there a reason, why there is such a high number of relays, which fail to specify a family, since this seams rather striking? aurel

2 1

relaytorkiri
by Nick Walke 03 Jan '12

03 Jan '12

I'm showing that tor is currently using 12 - 14 Mbps on my relay, however, the status page for my relay ( http://torstatus.blutmagie.de/router_detail.php?FP=192bdf2831c1b007a08dc3c1… ) does not reflect this speed. Is there a reason for this? Nick

4 7

Received botnet/drone abuse complaint
by Steve Snyder 03 Jan '12

03 Jan '12

I received a botnet/drone complaint from shadowserver.org today (delayed due to holidays) regarding my exit node: timestamp ip port type infection cc cc_port 12/29/2011 19:52 173.208.132.210 48586 32097 US MISSOURI KANSAS CITY tcp mebroot ukixxuug.com|MAOS/0EC20201 14DF137A55320641 84.163.151.128 80 3320 DE 1 If I'm reading this correctly, they identify "mebroot" as the source of the problem. As this is a Windows MBR trojan it obviously doesn't apply to my Linux system. I scanned my system anyway and found no unexpected processes running. My DirPort is set to 80, which may explain that value in the complaint. Any thoughts on what to do to avoid further complaints? Shadowserver addresses the topic of Tor exits here: http://www.shadowserver.org/wiki/pmwiki.php/Involve/TORNodesAndReporting Thanks.

2 1