- tor-relays - lists.torproject.org

Re: [tor-relays] Cheapest HW to get 20Mbit?
by Pi3 28 Aug '16

28 Aug '16

Hi Daniel, Judging from my pi3 mid relay where 5mbit traffic is about 20% of 1 core (tor uses 1 core mostly) 20-25mbit should be fine for pi3. In the peak hours it will be probably close to maximum what pi3 is capable on 1 core but when cost is a factor I would not think of anything else 1gb ram is more than enough, my tor uses about 150mb If you think of exit, cpu load may be higher

1 0

Re: [tor-relays] interesting network sockets pattern
by Toralf Förster 28 Aug '16

28 Aug '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/25/2016 07:02 PM, Toralf Förster wrote: > This is a fresh new Tor exit, setup 4 days ago, https://atlas.torproject.org/#details/BE2FA9FCB6242567B93ED99FEC5543FC517C9… , where I do wonder how to interpret the attached screen shot. The full SVG graphic can be derived from http://www.zwiebeltoralf.de/torserver/graph-20160825.svg (scroll down to the end) - -- Toralf PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF0EAREIAAYFAlfAOBwACgkQxOrN3gB26U7NEAD/U8eOOYq+sArqaGdrJ5+RzTUY G8duzPfhX6bbiI2u55cA93IBBN/7Hog4WhftxhM681ntxKk44KkYOryqyIaBZp4= =WWe1 -----END PGP SIGNATURE-----

4 7

Re: [tor-relays] interesting network sockets pattern
by Jivan Amara 27 Aug '16

27 Aug '16

> On Friday 26 August 2016 14:37:48 Toralf Förster wrote: >> On 08/25/2016 07:02 PM, Toralf Förster wrote: >>> This is a fresh new Tor exit, setup 4 days ago, >>> https://atlas.torproject.org/#details/BE2FA9FCB6242567B93ED99FEC5543FC517 >>> C9276 , where I do wonder how to interpret the attached screen shot. >> The full SVG graphic can be derived from >> http://www.zwiebeltoralf.de/torserver/graph-20160825.svg (scroll down to >> the end) > Hi Toralf, > > I see the same patterns on my relays from time to time. Please see my 2012 > posting https://lists.torproject.org/pipermail/tor-relays/2012-December/001781.html on [tor-relay] on that subject. I still have no idea what > causes the pattern. > > Regards, > > torland > I suspect this is due to a circuit built with a node that has lower max bandwidth settings than yours. The regular bandwidth cap holds traffic back for a time, then the burst bandwidth cap lets some through at a higher speed for a short period. -J

2 1

GeoIP
by Fred Rauch 27 Aug '16

27 Aug '16

Hi, I just started up another relay, and atlas' GeoIP data on it is incorrect (says it is in Netherlands when it is in fact in Lithuania). Where does Atlas get its GeoIP data from? Can this be corrected? It's not a huge issue but it would be nice for the correct country to be displayed. albino

3 2

Some information about Tor relays
by Liu, Zhuotao 26 Aug '16

26 Aug '16

Hi Folks, This is Sky from University of Illinois. Currently we are working on research project related with Tor. To help us to better design and evaluation our proposal, we need some information about the Tor relays that is currently unavailable from the Atlas. Thus, if someone who operates Tor relays could provide us such information, your help will be greatly appreciated. :) We hope to have an estimate about computation capacity of Tor relays. For instance, how many circuits a relay can maintain when its CPU is driven to about 100%? On average, how many circuits are maintained by a busy guard and what the CPU utilization is. These kinds of information would be really helpful. Further, in Sep 2013, Tor saw a spike in its clients. https://blog.torproject.org/blog/how-to-handle-millions-new-tor-clients The suspicion is that a botnet used Tor as its C&C channel. Is there any data about the relay utilization during that time? For instance, how many more circuits a relay had to maintain during that time? Thanks a lot for your help. :)

2 2

BSD buildbot: call for enrollment
by George 24 Aug '16

24 Aug '16

There is a BSD-focused buildbot at https://buildbot.pixelminers.net/ for admins running *BSD relays: FreeBSD, NetBSD, OpenBSD. . . The buildbot is a useful tool for Tor developers working on development versions of Tor. The BSDs are particularly important for a variety of reasons, including addressing portability issues with Tor code. Certainly the operating system monoculture problems with the Tor network shouldn't need any comments at this point (ie RFC5961). For those interested in enlisting their BSD relay, this TDP blog post provides more information: https://torbsd.github.io/blog.html#buildbot http://bptfp7py2wclht26.onion/blog.html#buildbot g -- 5F77 765E 40D6 5340 A0F5 3401 4997 FF11 A86F 44E2

2 3

Tor not running since last Debian update
by Martin Kepplinger 24 Aug '16

24 Aug '16

Hi So I think 2 days ago I updated tor on my debian stable machine and since then it's seen as not running anymore. It should be a relay. And locally it doesn't listen on port 9050, so it's not even a client now. My torrc hasn't changed. What's going on? Any config changes I missed? thanks martin

2 1

#torstrike
by Arisbe 24 Aug '16

24 Aug '16

7 6

halp #2
by Markus Koch 24 Aug '16

24 Aug '16

Sorry to bother you guys again Its 6am here and after reading the FAQ and other install guides I am out of ideas I just complied TOR (hurray!) on a NON-ROOT server. 1. Issue: I cant find the torrc file. I found out that the rest of the stuff is in ~./tor but no torrc at all. Where is it/should I put it? 2. Issue: I only need the complied TOR executable and I can safely delete all the other stuff? Cheers, Markus

2 2

HALP!
by Markus Koch 23 Aug '16

23 Aug '16

I just deleted my best running exit node to move to another vps. I copied /etc/tor and /var/lib/tor + keys dir and moved it to the new vps. I double-checked the files/keys are the same but i still get a new fingerprint. Wtf is wrong with me? Markus Sent from my iPad

5 9

Re: [tor-relays] GeoIP
by Tristan 23 Aug '16

23 Aug '16

Well, as canonizing ironize says on Tor's StackExchange, "GeoIP is bullshit." https://github.com/epidemics-scepticism/tor-misconception/blob/master/READM… On Aug 23, 2016 10:10 AM, "Fred Rauch" <albino(a)autistici.org> wrote: Hi, I just started up another relay, and atlas' GeoIP data on it is incorrect (says it is in Netherlands when it is in fact in Lithuania). Where does Atlas get its GeoIP data from? Can this be corrected? It's not a huge issue but it would be nice for the correct country to be displayed. albino _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

relay on a vps not exclusively used for tor?
by jensm1 23 Aug '16

23 Aug '16

Hi, I'm planning to get myself a small VPS for simple things like calendar-synching and backup of important data. Since these things are very light on resource-usage, I thought about putting a tor relay (non-exit) on the server, so it does something useful instead of idling most of the time. Is this advisable, or are there reasons why I shouldn't put a relay on a server that is used simultaneously by other things? Thanks for your advice!

8 13

Accounting and the 'Stable' flag
by Ralph Seichter 22 Aug '16

22 Aug '16

Hello list, I have enabled daily accounting on a non-exit Tor relay some days ago. On the first day, the transfer threshold was reached and the relay entered hibernation for a few hours, as expected. On the next day, I reduced RelayBandwidthRate to ensure that the accumulated transfer would fall just short of the AccountingMax value. During the last days, the relay has only been offline once for a couple of minutes (software update), besides the previously mentioned single hibernation period. As of today, the relay seems to have lost the 'Stable' flag, which I don't really understand. Am I missing something here? I could not find documentation mentioning a relationship between accounting and the 'Stable' flag. -Ralph

3 6

Re: [tor-relays] #torstrike
by Pi3 22 Aug '16

22 Aug '16

Or six-years-old-sandbox(a)lists.torproject.org This whole manifesto sounds like it was written by spoiled teenager or counter intelligence agent who is trying to incite unrest. Its designed to provoke emotions and doesn't deal with anything real. And I think its really awesome. This means that tor is a pain on someone's ass and doing its job for people who really need it. This someone is likely from said intelligence because spinning sexual scandals and building new stuff on those "scandals" is their way of doing their job where people get socially crucified without any evidence or legal conduct. Even when and _if_ such conduct happens it _always_ ends fast and without conclusions, but the harm was already made. Noise around tor is good for tor - it means its alive. Its just sad to see that people can get destroyed in this information war. Actually this stuff made me to slap another relay somewhere On Mon, Aug 22, 2016 at 9:08 AM, I <beatthebastards(a)inbox.com> wrote: This thread should be moved to [ tor-knitting-circle(a)lists.torproject.org ] or write to The Tor Corporation you think exists. Robert

1 0

Tiny computers (RPi-like) for exit nodes?
by Zack Weinberg 22 Aug '16

22 Aug '16

Has anyone had any experience running *exit* nodes on Raspberry Pi-grade hardware, or slightly beefier? We are thinking of replacing the old, bulky, power-hungry machine currently running exit 78C7C299DB4C4BD119A22B87B57D5AF5F3741A79 with something on that level. It only has to hit 10Mbps. thanks, zw

7 9

Re: [tor-relays] #torstrike
by AMuse 22 Aug '16

22 Aug '16

I'm not switching off my relay, primarily because I'm lazy and can't be arsed to figure out what all the politics bullshit is about. Some project member did some shit and other project members are mad at them. Other people may or may not be righteously mad at the first people for reasons I haven't bothered to learn. I started my relay so oppressed people in third world countries could communicate with the outside world and each other in relative safety. If that objective is still being achieved by the software, I could give a shit what beefs the coders have with each other. On Sun, Aug 21, 2016 at 8:14 PM, krishna e bera <keb(a)cyblings.on.ca> wrote: > On 21/08/16 10:02 PM, Zenaan Harkness wrote: > > Fact: Jacob Applebaum's directory authority was a target of NSA's > > XKEYSCORE: > > https://contraspin.co.nz/the-weaponising-of-social-part-3- > the-resurrection-of-ioerror/ > > Of course, perhaps they all are. > > > Fact: Jacob Applebaum got kicked from Tor Inc, prior to a proper > > investigation. > > Any organization would do the same with similar allegations. If he was > exonerated, he could rejoin afterwards. > > > > Fact: The investigation done by Tor Inc, was run by the primary accusers > > of Jacob Applebaum. > > Evidence? > > > > In the USA's war against Bradley Manning, Julian Assange, Wikileaks and > > Edward Snowden, Jacob Applebaum was a very high target, and caused the > > three letter agencies a lot of problems. > > > > So yes, operation of the network you use for -genuine- privacy needs, is > > very much dependent on those running the organisation. > > > > > > Fact: The ENTIRE board of Tor Inc got replaced after Jacob was given the > > boot! > > > > My conclusion: This was a coup, blunt and bloody, take no prisoners, > > respect no righteousness. > > Overdramatic. Where's the blood? Who was behind the coup, and what > hard evidence do you have? Are you looking for #torstrike to prompt > leaks of such info? > > Makes more sense for the Board to be distinct from the day to day > operations people anyway. > > > > My conclusion: The operation of the Tor directory authorities can no > > longer be trusted. > > Perhaps it never could be. Are you ready to run one? > > > > My conclusion: The deployment of TBB by Tor Inc can no longer be > > trusted. > > Fork it. > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

3 2

ExoneraTor down
by Alexander Dietrich 22 Aug '16

22 Aug '16

Hi, I just tried to use ExoneraTor, but it seems to be down: https://exonerator.torproject.org/ Best regards, Alexander -- PGP Key: https://dietrich.cx/pgp | 0x52FA4EE1722D54EB

4 4

Re: [tor-relays] relay on a vps not exclusively used for tor?
by Tristan 22 Aug '16

22 Aug '16

Honestly I have no idea how provides would enforce that rule anyway for that very reason. My guess is that it's a technicality, since Tor _can_ but isn't specifically _designed_ to max CPU usage. On Aug 21, 2016 10:47 PM, "Green Dream" <greendream848(a)gmail.com> wrote: >> > Most AUPs ban the use of programs designed to use 100% CPU >> >> A well-utilized Tor node will max out CPU... > > Mine hasn't. It peaks at about 30%. It can't even hit the 150Mbps limit I > set. Let me rephrase it then: a well-utilized Tor node _can_ max out CPU. I have two guard/middle nodes with maxed out cores. CPU is actually their bottleneck. They have high consensus weight and get a lot of use though. My point was just that if a VPS provider has a policy against software that maxes out CPU, Tor could cause that condition. Whether or not a provider would actually enforce this against a Tor node is another question. I haven't heard of it happening but ¯\_(ツ)_/¯ _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

issues with a fresh new tor server
by Toralf Förster 21 Aug '16

21 Aug '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I made the following steps to have /var/lib/tor encrypted under an ext4fs under a stable Gentoo Linux: at a local system: head -c 16 /dev/random | xxd -p > ~/tmp-salt.txt; echo 0x`cat ~/tmp-salt.txt` > ~/.cryptoSalt; rm ~/tmp-salt.txt picked up a password from: pwgen -s 16 open the remote directory: scp ~/.crypto{Pass,Salt} user@host:home; ssh user@host 'cat ~/.cryptoPass | sudo e4crypt add_key -S $(cat ~/.cryptoSalt) /var/lib/tor; rm ~/.crypto{Pass,Salt}' debug.log tells me: ... Aug 21 15:09:23.817 [notice] Opening Directory listener on [2a01:4f8:190:514a::2]:80 Aug 21 15:09:23.000 [warn] Your log may contain sensitive information - you're logging more than "notice". Don't log unless it serves an important reason. Overwrite the log afterwards. Aug 21 15:09:23.000 [debug] tor_disable_debugger_attach(): Attemping to disable debugger attachment to Tor for unprivileged users. Aug 21 15:09:23.000 [debug] tor_disable_debugger_attach(): Debugger attachment disabled for unprivileged users. Aug 21 15:09:23.000 [info] tor_lockfile_lock(): Locking "/var/lib/tor/data/lock" Aug 21 15:09:23.000 [warn] Couldn't open "/var/lib/tor/data/lock" for locking: Operation not permitted Aug 21 15:09:23.000 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.2.8.6 ) and indeed : # ls -alR /var/lib/tor/ /var/lib/tor/: total 12 drwxr-xr-x 3 tor tor 4096 Aug 21 15:09 . drwxr-xr-x 14 root root 4096 Aug 21 03:10 .. drwx------ 2 tor tor 4096 Aug 21 15:09 data - -rw-r--r-- 1 root root 0 Aug 19 14:47 .keep_net-misc_tor-0 /var/lib/tor/data: total 8 drwx------ 2 tor tor 4096 Aug 21 15:09 . drwxr-xr-x 3 tor tor 4096 Aug 21 15:09 .. Any hints ? - -- Toralf PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAle5qVMACgkQxOrN3gB26U6DKwD+KqNyqPlp3QvnSbC375p0sqe8 u9EeBJHUVX2xQxSIg9QA/icPTjMdK5iKh0uAgreqKi5T0g+JmxyGYg/Tp9ePJANl =w8Jd -----END PGP SIGNATURE-----

3 6

Question about the stable flag.
by tmbates12 21 Aug '16

21 Aug '16

Due to some problems with my VPS provider lately my relay hasn't been up consistently the past two weeks since it was created. I was wondering if it would be better to start from scratch again to get the stable flag considering my relay's bad history.

1 0

Guard Flag without stable Flag
by tmbates12 19 Aug '16

19 Aug '16

My relatively new Tor relay has somehow managed to get a Guard flag without having the Stable flag, I'm not sure if this is supposed to happen though..? https://atlas.torproject.org/#details/ABF5C38A93F2D7E77A226871AB0ADB052279B…

5 6

Relay vs exit node
by majacobs 18 Aug '16

18 Aug '16

Is my understanding correct that is NOT possible to run an accesspoint that connects to tor running a relay instead of an exit-node? I am able to torify programs running on the system , but need the acces point to be torified for some clients that need to go through tor. I am aware that this is possible if I run an exit node but my isp is seeing malware traffic every week or do if I do so... the white rider (Het leuke van ... is

2 1

Fwd: Problems with isp's onestrike policy
by majacobs 18 Aug '16

18 Aug '16

>> >> Cut off three times because of worm spread alert. I ran an exit node for just a couple of weeks. First came in while i was away on holiday . Could not connect to my vpn but noticed that one of my consumer routers send a reboot message around the first day of my vacation and didn't think about it again , that is till I got home and really started to run the node . Node 0d0a was running fine and well when the net was cut of for a second time just a few days before the third and last time. I contacted support , sought advice I was told to better run a relay. >> No way! I thought! >> To cut a story short, I know run in bridged mode (obsfs4proxy) but I am looking for solutions as to how Tor can help not seeing exit-nodes coming and going because of worm spreading? >> >> >> >> the white rider >> (Het leuke van ... is

3 4

Re: [tor-relays] Tiny computers (RPi-like) for exit nodes?
by Pi3 18 Aug '16

18 Aug '16

Im running 5 Mbits mid node on Pi3. Cpu load is 25-30% on 1 core with full steady traffic - no aes-ni here. Things should improve greatly when this ticket will go live in 0.2.9.x https://trac.torproject.org/projects/tor/ticket/7572

2 1

Abuse reports for non-exits
by Johan Nilsson 18 Aug '16

18 Aug '16

Hi, a directory authority IP-address on the DFRI network was recently reported for hosting malware and abuse reports was sent out to several mail addresses. Not only to abuse(a)dfri.tld as one would hope. The reason seems to have been malware using Tor connecting to the IP while analyzed in a sandbox. With the introduction of fallback directories abuse reports may become an issue for non-exit nodes. Just a heads up. Regards, Johan https://www.dfri.se

1 0

Local DNS on Exit logs failed user queries
by teor 18 Aug '16

18 Aug '16

Hi, When I set up a Tor Exit, I set up a local resolver (BIND) as a cache. Today, I was monitoring the syslog, and I noticed that BIND logs DNS names when resolution fails. (I have since removed these entries from the logs.) One way to prevent this is to disable logging on BIND entirely: logging { category default { null; }; }; Another is to isolate the categories that log DNS names, and disable them individually: logging { // these categories log DNS names category dnssec { null; }; category edns-disabled { null; }; category lame-servers { null; }; category resolver { null; }; category security { null; }; // also ignore uncategorised log messages category unmatched { null; }; }; I've updated the Tor wiki page on BIND with this configuration: https://trac.torproject.org/projects/tor/wiki/doc/BIND Does anyone know how to work out all the BIND categories that log DNS names? (All of the documentation I found online was helping people log *every* DNS query.) Or is it safer just to log a few essential categories? (Can anyone recommend any?) Has anyone checked if the logs on other resolvers (like unbound) have the same issue? Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org

4 4

Web server and TOR bridge at same IP:port
by Alen Hiew 17 Aug '16

17 Aug '16

Hello, listers! Is it possible to configure on own physical server a https Web server (for ex., Apache) at port 443 and obfs4 or meek bridge at same static global IP address and same port 443? It's something like SNI, not for two TLS web sites with different domain names at same IP but for web site on web server and TOR bridge. If this is possible it will be good masking for bridge because on others' requests this server will reply as simple https web server. As i understand, it will be difficult for observer without keys to distinguish encrypted bridge traffic from TLS-encrypted web traffic. If this is possible, can anyone tell about configuration manual/hits for this? WBR, Alan Hiew.

5 4

[WARN] Remote server sent bogus reason code 65021
by pa011 16 Aug '16

16 Aug '16

Just established a new Exit with two instances on (Linux 3.16.0-4-amd64) ,Tor 0.2.8.6 On the second instance I get these warnings: [WARN] Remote server sent bogus reason code 65021 [21 duplicates hidden] [WARN] Remote server sent bogus reason code 65023 [95 duplicates hidden] [NOTICE] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up. [40 duplicates hidden] The code65023 is ticking up by one in about 10 seconds? The default instance is free of that. Anything to worry about? Thanks Paul

1 1

A question about transfer - any advice?
by Charon 16 Aug '16

16 Aug '16

I'm running a Tor relay and everything is going great so far, but since I'm hosting on a commercial VPS, I have limited transfer (1 TB per month, overage: $0.02/GB). As such, I've set accounting to 10 GB per day so I'll at most use 620 GB in any given month and don't have to pay any overage costs. Q1: can I increase this limit without paying extra? I'm seeing that this 10 GB is hit very quickly, today within 9 hours. Q2: how can I adjust the bandwidth limit (80 Mb/s, burst 160 Mb/s) so that this 10 GB is more spread out over the day? Would it help to make this, say, 20 or 40 Mb/s? Thanks! Ps: if I haven't supplied sufficient details, please feel free to ask

2 1

Re: [tor-relays] Pi3 mid relay dropping lil bit of packets
by Pi3 16 Aug '16

16 Aug '16

Hmm I just noticed that systemd HUPs tor exactly every 24h and now I have 16 packets lost with 30gb relayed. Can this be the cause? Is there a way to log these drops without putting too much load on ram/cpu? Just to have a timestamp?

1 0

Re: [tor-relays] Pi3 mid relay dropping lil bit of packets
by Pi3 16 Aug '16

16 Aug '16

Ok thank you for replies, will keep an eye on this. On Tue, Aug 16, 2016 at 6:11 AM, Green Dream <greendream848(a)gmail.com> wrote: Counter-point... transmission errors are not a certainty: RX packets:323526978271 errors:0 dropped:0 overruns:0 frame:0 TX packets:249565709357 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:285274358053849 (285.2 TB) TX bytes:287754558279252 (287.7 TB) Ideally there should be no errors. :) 11 dropped packets isn't a big deal, but I wouldn't be quick to dismiss these errors by default. In certain cases things might be improved with driver updates, or sysctl tweaks, or a new ethernet cable, etc. _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

spelling mistake
by I 16 Aug '16

16 Aug '16

2 1

Pi3 mid relay dropping lil bit of packets
by Pi3 16 Aug '16

16 Aug '16

Hello, I just started running my little 5 mbits mid relay on Pi3 on raspbian and all seems to be dandy, it picked traffic nicely, hovering around 700-800 total connections, its not unusual to see it pushing full advertised bandwidth during peak hours (with ~20-25% load on 1 core, multithread pls come already), tldr so far nice. Except with 3days uptime and 20 gigs of data relayed ifconfig shows 11 (eleven) packets dropped on eth0. Google says it can be ring buffer on NIC getting full, but ethtool -g eth0 says Ring parameters for eth0: Cannot get device ring settings: Operation not supported ethtool -S eth0 = no stats available Htop avg load is 0.30, tor uses 121/950mb of ram. Im running standard conntrack cstate established related iptable rule with default drop. Pi3 is in LAN behind modem nat. It worries me because if I get more consensus, drops will probably go up. I didnt apply any sysctl tweaks. Using official deb NIC is Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter and its internally connected to usb2 by design - it shows under lsusb. ethtool says 100Mb/s full duplex. Tor log is clean with only heartbeat in it, syslog seemed ok also if I didnt miss anything. Or is it so marginal I should forget about it? Im not sure what should I do about it, any suggestions are welcomed. Thanks

4 3

obfs4 - git how to ?
by Petrusko 15 Aug '16

15 Aug '16

Trying to use obfs4 from git on a test bridge : With "root" user: cd /home/TEST git clone https://git.torproject.org/pluggable-transports/obfs4.git ln -s /home/TEST/obfs4/obfs4proxy /usr/bin/obfs4proxy torrc file : [...] ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy managed ServerTransportListenAddr obfs4 0.0.0.0:48001 In the log when starting Tor : [...] [warn] Could not launch managed proxy executable at '/usr/bin/obfs4proxy' ('Permission denied'). [...] Tor is still working and is connected to the network... Humm, I think I've not understand how to use this source, and how to manage it ?! Thx for you help :) -- Petrusko PubKey EBE23AE5 C0BF 2184 4A77 4A18 90E9 F72C B3CA E665 EBE2 3AE5

4 4

Re: [tor-relays] Pi3 mid relay dropping lil bit of packets
by Tristan 15 Aug '16

15 Aug '16

Personal opinion here: 11 packets dropped on 20GB of data sounds pretty small, and these packets might not even be from Tor. Literally any network service could have dropped those packets (ntp, ssh, updates, etc.) I wouldn't worry about it unless it starts to dramatically increase. On Aug 15, 2016 1:08 PM, "Pi3" <tor-relays(a)mixbox.pl> wrote: Hello, I just started running my little 5 mbits mid relay on Pi3 on raspbian and all seems to be dandy, it picked traffic nicely, hovering around 700-800 total connections, its not unusual to see it pushing full advertised bandwidth during peak hours (with ~20-25% load on 1 core, multithread pls come already), tldr so far nice. Except with 3days uptime and 20 gigs of data relayed ifconfig shows 11 (eleven) packets dropped on eth0. Google says it can be ring buffer on NIC getting full, but ethtool -g eth0 says Ring parameters for eth0: Cannot get device ring settings: Operation not supported ethtool -S eth0 = no stats available Htop avg load is 0.30, tor uses 121/950mb of ram. Im running standard conntrack cstate established related iptable rule with default drop. Pi3 is in LAN behind modem nat. It worries me because if I get more consensus, drops will probably go up. I didnt apply any sysctl tweaks. Using official deb NIC is Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter and its internally connected to usb2 by design - it shows under lsusb. ethtool says 100Mb/s full duplex. Tor log is clean with only heartbeat in it, syslog seemed ok also if I didnt miss anything. Or is it so marginal I should forget about it? Im not sure what should I do about it, any suggestions are welcomed. Thanks _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

Do middle nodes create multiple connections to the same Exit node? (with different source port)
by don.gould＠tuta.io 15 Aug '16

15 Aug '16

Hello, Do middle nodes create multiple connections to the same Exit node? (with different source port) The reason I ask is because I am a little confused. Even the tor relay operators are completely honest and don't log anything, the ISP / upstream ISP could still log all the connections. So they can see: [MiddleNode IP]:[Source Port] ==> [ExitNode IP]:[Dest Port (ORport)] -- Timestamp + Duration of connection. So if I create a long running ssh connection that is going for 6 hours this will be unique to the middle node. During this 6 hours, if another tor client chooses the same MiddleNode + ExitNode, does the MiddleNode create a new connection to the ExitNode? (Can be found out using netstat) Or does it use the same connection that it already has established with the exit node? Thanks.

2 1

High speed Tor relay advice
by i3 15 Aug '16

15 Aug '16

Hi all, I've ran multiple Tor relays before but I have moved to a new server and would like some advice. My new server has 10Gb/s connection (I've observed it at 900MB/s to the drives) with plenty of CPU and RAM to complement. I typically use default configurations on my relays but I feel that to get the most out of this one I'll need to do some configuration to tweak it. Does anyone have advice on getting the most out of this server, in terms of speed? Thanks

10 14

90% of exits vulnerable to TCP off-path attack
by starlight.2016q3＠binnacle.cx 14 Aug '16

14 Aug '16

RFC-5961 CVE-2016-5696 http://www.theregister.co.uk/2016/08/10/linux_tor_users_open_corrupted_comm… FYI all

5 4

How to exclude a CDN ?
by Toralf Förster 13 Aug '16

13 Aug '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Got few times an informal report containing something like: It is most likely the attack traffic is directed at one of the following endpoints: account.sonyentertainmentnetwork.com auth.np.ac.playstation.net auth.api.sonyentertainmentnetwork.com auth.api.np.ac.playstation.net I was just wondering how would somebody handle a request to exclude those IP addresses, b/c 2 attempts to get the affected netwrok gives: # host account.sonyentertainmentnetwork.com account.sonyentertainmentnetwork.com is an alias for account.sonyentertainmentnetwork.com.edgekey.net. account.sonyentertainmentnetwork.com.edgekey.net is an alias for e380.b.akamaiedge.net. e380.b.akamaiedge.net has address 104.109.72.158 # whois 104.109.72.158 | grep CIDR CIDR: 104.64.0.0/10 CIDR: 104.109.64.0/20 and at another system : ~/devel/wireshark $ host account.sonyentertainmentnetwork.com account.sonyentertainmentnetwork.com is an alias for account.sonyentertainmentnetwork.com.edgekey.net. account.sonyentertainmentnetwork.com.edgekey.net is an alias for e380.b.akamaiedge.net. e380.b.akamaiedge.net has address 184.24.193.168 $ whois 184.24.193.168 | grep CIDR CIDR: 184.24.0.0/13 CIDR: 184.24.192.0/20 - -- Toralf PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAleqBwUACgkQxOrN3gB26U7YXQD+PHgO8nVRo01abzdu1P7zC6TZ gDMkb+L51zt/k7hBJOsA/0czdSd8p8AnINKx+FP2Gi5ZSjVzzBuUM9o+htw5BdIX =Tz+I -----END PGP SIGNATURE-----

4 5

Re: [tor-relays] 90% of exits vulnerable to TCP off-path attack
by starlight.2016q3＠binnacle.cx 13 Aug '16

13 Aug '16

At 12:01 8/12/2016 -0400, Zack Weinberg wrote: >Also, if you read the paper, raising the global rate limit (as >suggested by the reg. article) doesn't help; it only slows the >attacker down a little. The paper indicates that a global counter limit other than 100 can be easily discovered. However the recommended mitigation effectively removes the global counter by setting it to 10^9. The described attack requires the counter be exhausted inside the temporal bounds of one second and the Internet as it exists today cannot support 10^9 probes on that deadline. IMO the recommended mitigation is effective and should be applied by those believing RFC-5961-as-presently- implemented changes worse than the weaknesses addressed by the RFC. I applied the mitigation.

2 1

90% of exits vulnerable to TCP off-path attack
by starlight.2016q3＠binnacle.cx 12 Aug '16

12 Aug '16

[one last time, no DKIM for Tor lists nevermore] RFC-5961 CVE-2016-5696 http://www.theregister.co.uk/2016/08/10/linux_tor_users_open_corrupted_comm… FYI all

2 1

Re: [tor-relays] 90% of exits vulnerable to TCP off-path attack
by Tristan 12 Aug '16

12 Aug '16

According to Ark Technica ( http://arstechnica.com/security/2016/08/linux-bug-leaves-usa-today-other-to…) encrypted communications can only be blocked, meaning that exit servers could still be targeted. However, the bug only has to affect 1 side in order to work. So even if every exit node patched it, Tor users (and the regular Internet) would still be vulnerable until the Web servers patch it as well. Either way, it'll be a while before everyone is patched. On Aug 12, 2016 11:01 AM, "Zack Weinberg" <zackw(a)cmu.edu> wrote: On Fri, Aug 12, 2016 at 11:27 AM, <starlight.2016q3(a)binnacle.cx> wrote: > RFC-5961 > CVE-2016-5696 > http://www.theregister.co.uk/2016/08/10/linux_tor_users_ open_corrupted_communications/ > FYI all Tor's use of TLS _should_ mean that the worst an attacker can do here is denial-of-service. The Register article suggests that they might also be able to force the use of specific exit relays (by disrupting connections that don't go through those relays) but weaponizing that against specific users (rather than everyone trying to use an exit the attacker doesn't like) strikes me as nontrivial. Also, if you read the paper, raising the global rate limit (as suggested by the reg. article) doesn't help; it only slows the attacker down a little. Right now I think one should not panic and should wait for the kernel people to do a proper fix. zw _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

90% of exits vulnerable to TCP off-path attack
by starlight.2016q3＠binnacle.cx 12 Aug '16

12 Aug '16

[second try here for clean DKIM authentication] [listsrv added a two spaces instead of one] RFC-5961 CVE-2016-5696 http://www.theregister.co.uk/2016/08/10/linux_tor_users_open_corrupted_comm… FYI all

1 2

Out of memory: Kill process (tor)
by Tristan 12 Aug '16

12 Aug '16

Last night I received my first abuse complaint on DigitalOcean. When I logged in, I saw Tor was no longer running because the system ran out of memory. Is it possible the system ran out of memory because of the abuse? My relay has 512MB of RAM running Tor and Unbound, and it's been running fine all month. How can I prevent this memory issue from happening in the future? Thanks -- Finding information, passing it along. ～SuperSluether

2 1

running a relay on a pi/pi2 and it stopped working after upgrading to 0.2.8.6/0.2.8.6-2 ? read this (bugfix)
by Hack-Tic 10 Aug '16

10 Aug '16

Hi, I ran into some tor restart loop issues after upgrading to 0.2.8.6 on my pi2 relay. In short, it takes too long to read router_parse_list_from_string and hits the systemd start timeout limit causing a restart (and loop) Full story in the ticket here: https://trac.torproject.org/projects/tor/ticket/19819 quick fix: edit /lib/systemd/system/tor(a)default.service and change TimeoutStartSec= from 120 to 300 Hope i'm not "spamming" the list, just trying to help. Have a good one.

4 4

DoS on my non-exit relay? Or just oversensitive DoS "protection"?
by Sebastian Niehaus 10 Aug '16

10 Aug '16

Hi, The provider of my non-exit "silentrocket" told me they temporarily disconnected the server from their network because of a DoS attack against the machine. https://atlas.torproject.org/#details/7A32C9519D80CA458FC8B034A28F5F6815649… They sent me some details of what they think is a DoS attack (date and time omitted ...): ########################################### Attack type: DoS_IN Attacked IP: 82.223.21.74 ########################################### Source Address Source Port Destination Address Destination Port Frames 193.171.202.146 TCP:9001 82.223.21.74 TCP:61078 21440736 176.10.104.243 TCP:443 82.223.21.74 TCP:25817 11203344 185.29.8.132 TCP:443 82.223.21.74 TCP:56708 8160360 58.58.170.2 TCP:443 82.223.21.74 TCP:61980 7840824 144.76.14.145 TCP:143 82.223.21.74 TCP:19866 6240664 195.154.209.91 TCP:443 82.223.21.74 TCP:20229 4808568 192.42.113.102 TCP:9001 82.223.21.74 TCP:62658 4328568 83.146.80.152 TCP:39898 82.223.21.74 TCP:9001 3041584 87.98.162.251 TCP:443 82.223.21.74 TCP:60948 2240040 188.138.9.49 TCP:9001 82.223.21.74 TCP:13349 2240000 93.145.122.187 TCP:60469 82.223.21.74 TCP:9001 1920016 104.236.92.66 TCP:1337 82.223.21.74 TCP:48838 1760248 5.248.227.163 TCP:9001 82.223.21.74 TCP:28976 1760240 109.104.12.92 TCP:9001 82.223.21.74 TCP:15808 1601224 46.101.237.246 TCP:9001 82.223.21.74 TCP:18393 1600784 212.47.239.187 TCP:443 82.223.21.74 TCP:6669 1600000 212.117.180.130 TCP:443 82.223.21.74 TCP:37114 1440000 37.187.17.67 TCP:38547 82.223.21.74 TCP:9001 1281176 37.157.193.107 TCP:49192 82.223.21.74 TCP:9001 804896 193.11.164.243 TCP:9001 82.223.21.74 TCP:62265 800040 I am not sure whether it really looks like a DoS attack or if is just many "normal" tor packets hammering on the small server which are misunderstood as a DoS. They are coming from a remote's maschines tor port and going to some random port om my server suggesting the packets are simply a reply to some connection my server opened. The server ran fine for several months but now I get a disconnection notice several times a day. Maybe there is really a DoS, maybe their automatic DoS protection reacts too fast, maybe they are just fed up with the traffic the relay causes and want to make things hard for me. Do you have any (educated) guesses what might be going on here? Thank you very much, Sebastian

2 2

Unsubscribe
by Jeremy 09 Aug '16

09 Aug '16

Unsub Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. -------- Original Message -------- Subject: tor-relays Digest, Vol 67, Issue 22 Local Time: August 8, 2016 2:00 AM UTC Time: August 8, 2016 12:00 PM From: tor-relays-request(a)lists.torproject.org To: tor-relays(a)lists.torproject.org Send tor-relays mailing list submissions to tor-relays(a)lists.torproject.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays or, via email, send a message with subject or body 'help' to tor-relays-request(a)lists.torproject.org You can reach the person managing the list at tor-relays-owner(a)lists.torproject.org When replying, please edit your Subject line so it is more specific than "Re: Contents of tor-relays digest..." Today's Topics: 1. Re: tor-relays Digest, Vol 67, Issue 12 (grarpamp) 2. Re: is explicit DirPort needed anymore under Tor 0.2.8.6? (teor) 3. Re: [PATCH] debian package upgrade restart issue (nusenu) ---------------------------------------------------------------------- Message: 1 Date: Mon, 8 Aug 2016 01:40:59 -0400 From: grarpamp <grarpamp(a)gmail.com> To: tor-relays(a)lists.torproject.org Cc: flipchan(a)riseup.net Subject: Re: [tor-relays] tor-relays Digest, Vol 67, Issue 12 Message-ID: <CAD2Ti2-2R0KE+KA6EkMwVftA8G8Bi9OV4sYr0k=a-5CD=WeFtg(a)mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On 8/5/16, Flipchan <flipchan(a)riseup.net> wrote: > [bad netiquette] When replying to digests... - At minimum, change the subject to the original subject. Optimally also include proper header threading. Repliers should subscribe to per message distribution instead. - Delete all content from the original except some minimum needed to establish context to which you are replying, instead of spamming out longquotes of already said longtext. - Reply inline below each piece of context to which you are replying, instead of top posting. ------------------------------ Message: 2 Date: Mon, 8 Aug 2016 17:33:42 +1000 From: teor <teor2345(a)gmail.com> To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] is explicit DirPort needed anymore under Tor 0.2.8.6? Message-ID: <6AABDA0A-4835-4B2C-A60D-A7A64568BE65(a)gmail.com> Content-Type: text/plain; charset="utf-8" > On 3 Aug 2016, at 10:29, teor <teor2345(a)gmail.com> wrote: > > Clients on 0.2.7.6 and earlier still use the IPv4 DirPort. > (Tor Browser is still 0.2.7.6, and apps in general may take some time to upgrade.) > > Authorities on0.2.7.6 and earlier will only assign the HSDir flag to relays with an IPv4 DirPort. > (Authorities may take some time to upgrade, because running different versions increases authority diversity.) For the record, even though the man page entry for HidServDirectoryV2 says the DirPort is not required to be a HSDir, authorities on 0.2.7 and earlier still check for it before assigning the HSDir flag. Authorities on 0.2.8 and later behave in a way that's consistent with HidServDirectoryV2, assigning the HSDir flag to any relay that wants to be a HSDir, and either supports being a directory cache, or has a DirPort. HidServDirectoryV2 0|1 When this option is set, Tor accepts and serves v2 hidden service descriptors. Setting DirPort is not required for this, because clients connect via the ORPort by default. (Default: 1) > Fallback directory mirrors must have a DirPort, and we'd only think about changing that when: > * all recommended relay versions are 0.2.8 and later, and > * relays no longer fetch documents using the DirPort (so maybe never). > > All relays running any Tor version will continue to use the IPv4 DirPort to fetch consensuses from other relays. > > So we haven't obsoleted the IPv4 DirPort yet. We've just made sure that clients fetch directory documents over an encrypted channel. Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org

2 1

is explicit DirPort needed anymore under Tor 0.2.8.6?
by Green Dream 08 Aug '16

08 Aug '16

The release notes for Tor 0.2.8.6 have this tidbit about the DirPort: "Previously only relays that explicitly opened a directory port (DirPort) accepted directory requests from clients. Now all relays, with and without a DirPort, accept and serve tunneled directory requests that they receive through their ORPort. You can disable this behavior using the new DirCache option. Closes ticket 12538." With this new behavior, is there any reason to keep an open DirPort on our relays? If I just use an ORPort on 443 (or another reachable TCP port) is this sufficient? Might it make sense to leave the DirPort up for a while for legacy clients? Will (up-to-date) authorities have any concerns with a ORPort-only relay? Thanks.

5 7

Re: [tor-relays] tor-relays Digest, Vol 67, Issue 12
by Flipchan 08 Aug '16

08 Aug '16

I would recommend port knocking if u run ssh tor-relays-request(a)lists.torproject.org skrev: (4 augusti 2016 19:30:11 CEST) >Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > >You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of tor-relays digest..." > > >Today's Topics: > > 1. Re: tor-relays Digest, Vol 67, Issue 11 (Flipchan) > 2. Re: Exit relay funding (I) > 3. Re: Exit relay funding (Petrusko) > 4. Re: Any security tips on running a TOR relay? (Green Dream) > 5. Re: Any security tips on running a TOR relay? (Tristan) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Thu, 04 Aug 2016 14:51:35 +0200 >From: Flipchan <flipchan(a)riseup.net> >To: tor-relays(a)lists.torproject.org >Subject: Re: [tor-relays] tor-relays Digest, Vol 67, Issue 11 >Message-ID: <A571C798-B2DE-4A1C-B2CA-EB58353A0D72(a)riseup.net> >Content-Type: text/plain; charset="utf-8" > >Auto update with cron, audit it like a normal server > >tor-relays-request(a)lists.torproject.org skrev: (4 augusti 2016 14:00:07 >CEST) >>Send tor-relays mailing list submissions to >> tor-relays(a)lists.torproject.org >> >>To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>or, via email, send a message with subject or body 'help' to >> tor-relays-request(a)lists.torproject.org >> >>You can reach the person managing the list at >> tor-relays-owner(a)lists.torproject.org >> >>When replying, please edit your Subject line so it is more specific >>than "Re: Contents of tor-relays digest..." >> >> >>Today's Topics: >> >> 1. Re: experiences with debian tor 0.2.8.6 package from >> deb.torproject.org (tor relay) >> 2. Any security tips on running a TOR relay? (Andrew) >> 3. Re: Exit relay funding (Petrusko) >> 4. Re: experiences with debian tor 0.2.8.6 package from >> deb.torproject.org (Peter Palfrader) >> >> >>---------------------------------------------------------------------- >> >>Message: 1 >>Date: Thu, 4 Aug 2016 08:01:32 +0200 (CEST) >>From: tor relay <torrelay3(a)mailbox.org> >>To: tor-relays(a)lists.torproject.org >>Subject: Re: [tor-relays] experiences with debian tor 0.2.8.6 package >> from deb.torproject.org >>Message-ID: <249633305.6901.1470290492290(a)office.mailbox.org> >>Content-Type: text/plain; charset="utf-8" >> >>https://trac.torproject.org/projects/tor/ticket/19825 >>

2 1

minor typos in tor-instance-create
by tor relay 06 Aug '16

06 Aug '16

https://gitweb.torproject.org/debian/tor.git/tree/debian/tor-instance-creat… is: systemctl tor@$name start should be: systemctl start tor@$name mailto:tor@$name https://gitweb.torproject.org/debian/tor.git/tree/debian/tor-instance-creat… brdige -> bridge

2 2