- tor-relays - lists.torproject.org

Re: [tor-relays] stats
by Armand 07 Jul '13

07 Jul '13

Sent from my Cricket smart phone ma455(a)mykolab.com wrote: >hello, >i'm running an exit node from 2 or 3 month, in UA, on a vps, xeon 2650 >2Ghz, 128mb RAM, debian 6 >tor v0.2.3.25-1 > > >on atlas there is some stat on those days it's seem to be at max 100Kb/s > > > > > > > >//atlas.torproject.org/#details/62C3FB37C44555E55A62BBD7CDDD97FE4894F317 > >but on arm or with iftop i'm beetween 300 and 900Kb/s download and the >same in upload > >my load average is 4.74, 2.97, 2.98 >there is just tor on this server > >this append form the beguining, > >there is a problem? who is right? can you help me to verify if my node >is fine configured? > > >thanks > >PS: sorry for my english is not my first language >_______________________________________________ >tor-relays mailing list >tor-relays(a)lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

3 2

stats
by ma455＠mykolab.com 07 Jul '13

07 Jul '13

hello, i'm running an exit node from 2 or 3 month, in UA, on a vps, xeon 2650 2Ghz, 128mb RAM, debian 6 tor v0.2.3.25-1 on atlas there is some stat on those days it's seem to be at max 100Kb/s //atlas.torproject.org/#details/62C3FB37C44555E55A62BBD7CDDD97FE4894F317 but on arm or with iftop i'm beetween 300 and 900Kb/s download and the same in upload my load average is 4.74, 2.97, 2.98 there is just tor on this server this append form the beguining, there is a problem? who is right? can you help me to verify if my node is fine configured? thanks PS: sorry for my english is not my first language

2 2

Re: [tor-relays] stats
by Armand 07 Jul '13

07 Jul '13

Sent from my Cricket smart phone ma455(a)mykolab.com wrote: >hello, >i'm running an exit node from 2 or 3 month, in UA, on a vps, xeon 2650 >2Ghz, 128mb RAM, debian 6 >tor v0.2.3.25-1 > > >on atlas there is some stat on those days it's seem to be at max 100Kb/s > > > > > > > >//atlas.torproject.org/#details/62C3FB37C44555E55A62BBD7CDDD97FE4894F317 > >but on arm or with iftop i'm beetween 300 and 900Kb/s download and the >same in upload > >my load average is 4.74, 2.97, 2.98 >there is just tor on this server > >this append form the beguining, > >there is a problem? who is right? can you help me to verify if my node >is fine configured? > > >thanks > >PS: sorry for my english is not my first language >_______________________________________________ >tor-relays mailing list >tor-relays(a)lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Address mismatch on received DNS packet
by TonyXue 05 Jul '13

05 Jul '13

Hi Everyone, I've just started to run a tor relay these days. But there are many warnings like this in my log file. Jul 05 11:25:19.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.234:53Jul 05 11:25:38.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.235:53Jul 05 11:25:42.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.235:53Jul 05 11:32:18.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.235:53Jul 05 11:32:18.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.235:53Jul 05 11:32:18.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.234:53Jul 05 11:32:18.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.234:53Jul 05 11:32:23.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.236:53Jul 05 11:39:14.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.235:53Jul 05 11:39:48.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.235:53Jul 05 11:39:48.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.235:53Jul 05 11:39:48.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.235:53Jul 05 11:39:48.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.234:53Jul 05 11:39:48.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.236:53Jul 05 11:39:53.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.234:53Jul 05 11:39:53.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.234:53Jul 05 11:39:58.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 66.80.130.235:53 Also with some warnings: Jul 05 12:36:58.000 [warn] eventdns: All nameservers have failedJul 05 12:36:58.000 [notice] eventdns: Nameserver 64.81.45.2:53 is back up Is the nameservers mentioned above are set to be Tor's resolvers? If they are, where can I change the settings of DNS servers? Hope someone can help me with this... Thanks a lot.

3 2

Vidalia can't open Tor after machine restart
by Shane Nagle 04 Jul '13

04 Jul '13

Hello Tor team! And thanks so much for doing what you do. I have a novice/newbie question. Perhaps you could point me to the best source of problem solving data/info you have regarding it. My problem is: after successfully downloading TBB 64bit, and having the browser work very well all day, I shut down my machine at night, then restart the next day only to find that Vidalia cannot open Tor. I've done this four times now. The 'temporary solution' each time was to uninstall, re-download and install TBB again. However the same errors would occur the following morning. I see this: in the fIrefox interface - Firefox is configured to use a proxy server that is refusing connections. And in the Vidalia pane: Vidalia was unable to connect to Tor. (Connection refused by peer.) I have sent several emails to the Tor mailing lists but so far have heard no reply or seen any posting of my inquiry. Any support would be appreciated. S

2 1

Summary of v0.2.3.x --> v0.2.4.x changes?
by Steve Snyder 04 Jul '13

04 Jul '13

Now that Tor v0.2.4.x has reached Release Candidate status, could someone please inform those who haven't been following the development process what is new? I just mean the broad strokes. Like: What changes to a working relay are required or recommended when moving to v0.2.4.x? What are the major new features of this release? (Any benefit now to using more than 2 CPU cores? IPv6 support for non-bridge relays? That sort of thing.) Thanks.

2 1

Re: [tor-relays] [tor-talk] Theft of Tor relay private keys?
by Mike Perry 03 Jul '13

03 Jul '13

thomas.hluchnik(a)netcologne.de: > Hello all, please help me understanding this: > > supposed, the NSA were able to break into a large scale of tor nodes, > stealing the tor private server key. At the same time they were able > to gather all traffic they can get. Wouldnt this increase the > likelihood that data from complete circuits can be decrypted and > traced back to the original sender? If their intercepts are passive, merely stealing relays' private identity key won't accomplish much because Tor uses Forward Secrecy for both the relay TLS links and for circuit setup. https://en.wikipedia.org/wiki/Perfect_forward_secrecy However, if their intercepts are active (as in they can arbitrarily manipulate traffic in-flight), then stealing either Guard node keys or directory authority keys allows complete route capture and traffic discovery of targeted clients. So you are right to worry about this, in my opinion. I am also very concerned. I want to make some changes to Tor to make such key theft easier to detect, less damaging, and harder to make use of: https://trac.torproject.org/projects/tor/ticket/7126 https://trac.torproject.org/projects/tor/ticket/5968 However, I want to do a lot of other things in 0.2.5.x though too, and there's this whole browser thing that I'm technically supposed to be paying attention to too, so I might not get to those. :/ That first one (#7126) is probably a good volunteer/student project for someone who likes Python, though. It would be easy to make a prototype with Stem, txtorcon, or even TorCtl. > Maybe this is paranoid, but this arises the question for me: what > would happen when I stop my tor node once a week, throw away my keys > and restart tor so that new server keys were generated. So NSA would > have to break into my system again, but this would make it harder for > NSA agency to decrypt circuits where my host is involved. I am in favor of regular identity key rotation for relays, and I want to work towards supporting that better by default: https://trac.torproject.org/projects/tor/ticket/5563 I think keeping your keys on a ramdisk or encrypted filesystem with a memory-only random key (so if you experience unexplained reboots, etc they go away) is a good idea. Also, since Tor reads/creates its identity key at startup and doesn't need the file afterwords, you can even 'shred'/'wipe' it after that, so the adversary can't easily pull them off the FS while the system is running. Better still, you can load a Kernel module to disable gdb debugger support so the adversary has to actually dig through/manipulate raw memory to get the key (which will be error prone and is more likely to lead to crashes/panics/reboots): https://gist.github.com/1216637 I started describing these and related ideas here: https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity But I got distracted by more pressing issues before I could finish the scripts.. Also, many of those encrypted+authenticated Tor container things probably don't make much sense without Secure Boot to authenticate the boot process up until you can start up Tor. :/ > What were the disadvantages for the tor network? Would this confuse > the tor director in any way? Sort of. Weekly identity key rotation is too frequent to recommend for people to do for a few reasons. First, it takes the bandwidth measurement servers a couple days to ramp up your capacity of your new identity key, so you will spend a lot of time below your max throughput. Second, you would also likely never get the Guard flag. Third, there are also load balancing issues with Guard nodes where as soon as you get the Guard flag, it will take 1-2 months before clients switch to your new Guard, so you will also likely spend that time at less than your full capacity. > Would it be able to keep the nickname or would it have to change also? > Would this have effect on the onion address if I had a hidden server? No and no, but your hidden server might have brief downtimes/descriptor publish times that correlate with your key rotation. Not sure how severe that is in practice. -- Mike Perry

2 1

Exit node with bad time.
by Bernard Tyers - ei8fdb 02 Jul '13

02 Jul '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, I am running an exit node on a VPS. For some reason (I've opened a support ticket) a) my systems clock is off by 2 hours (even though its hosted in CEST land) and b) I cannot change it, even though I am root. As a result, I am getting recurring skewed time errors as below: Accounting (awake) Time to reset: 29:12:02:58 21 GB / 1 PB 22 GB / 1 PB Events (TOR/ARM NOTICE - ERR): │ 12:25:39 [WARN] Received directory with skewed time (server '86.59.21.38:80'): It seems that our clock is ahead by 2 hours, 3 minutes, or that theirs is behind. Tor requires an accurate clock to work: please check your time, timezone, and date settings. │ 12:25:03 [WARN] Received NETINFO cell with skewed time from server at 76.73.17.194:9090. It seems that our clock is ahead by 2 hours, 3 minutes, or that theirs is behind. Tor requires an accurate clock to work: please check your time and date settings. I haven't found any mention in the archives of this (except [1] which is NOT the same, just mentions wrong time), if it results in issues to the network overall. Until I can get it resolved (today hopefully) is there any negative affects on the network of having a node with bad time? thanks, Bernard [1] https://lists.torproject.org/pipermail/tor-relays/2011-November/001001.html - -------------------------------------- Bernard / bluboxthief / ei8fdb IO91XM / www.ei8fdb.org -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJR0o/WAAoJENsz1IO7MIrr8SoIALW8W1+SawsVv6r2sLCEPetp u05dGZ4E2vyuey5VIRfPsG1Lc2kPmE+dzY2jgHm2Q66htBqMXtv+WQ1P8TMBYyzj ke/LkXOW2aE2NkyJ95navfnImJGWS+Ie4eyk+PnHL0d6RoRc9K2JKnQKTCPLRQvQ kiFUkKWuHVn/aRzalrlKH7yFdoPosh5pdqqyRLQ4sDQ0dAye0u4GxfvMsrdCP8oO ediSXiRaupSr24V+yK7ceZNUiEBcdNp6VudwJXQ+YH1uF4obSHeVWQFC7ZRpAbAI VrqNVqBx7Xbij0wC83VR6ifz/AYJNoKlG56H72w/jg1hVwi7x58CIuLWBOm1bUM= =2AY7 -----END PGP SIGNATURE-----

2 2

Tor Exit Node and Skype
by var 28 Jun '13

28 Jun '13

Hello everybody, I am running a Tor exit node since some year´s. In the last month I experienced problems with Skype. Skype won´t connect anymore....but if I shutdown the EXIT NODE Skype connects again. Just want to ask all of you if you experienced similar problems? I also opened a ticket at Skype.com So if you got the same problem like me pls go there and post some additional information. > http://community.skype.com/t5/Security-Privacy-Trust-and/Is-Skype-blocking-… Cheers VarVarna

6 5

Munin graphs from fast relays before/after crypto acceleration
by Karsten Loesing 19 Jun '13

19 Jun '13

Hi fast-relay operators, I'm looking for some Munin graphs (or similar) showing the effect of turning on crypto acceleration on fast relays. Does anyone have such graphs to share that show decrease in CPU load and corresponding increase in bandwidth use? Thanks! Karsten

1 0