- tor-relays - lists.torproject.org

OT: folding@home
by Sebastian Urbach 28 Dec '14

28 Dec '14

Dear list members, I would like to invite any operator, who has some idle Cores (CPU or GPU) left,to join the folding@home distributed computing project: http://folding.stanford.edu/ There is now a brandnew team called Tor Project (Unofficial) with the id 227615. Hope to see some of you there :-) -- Sincerely yours / Sincères salutations Sebastian Urbach ----------------------------------------- Definition of Tor: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

6 10

boost CPU on a Tor relay
by s7r 28 Dec '14

28 Dec '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, A Tor relay currently going 33MB/s could go a lot faster but CPU is at 93% usage - this is the bottleneck. Here is the output of /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz stepping : 5 microcode : 0x11 cpu MHz : 3068.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi flexpriority ept vpid bogomips : 6132.24 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: it also goes down to processor 1 - processor 7 Any ideas how this could be boosted? OS is Debian wheezy. No aes-ni hardware acceleration, no openssl benchmarking or customization currently. advices? Thank you. - -- s7r PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUDuRTAAoJEIN/pSyBJlsRLqYH/iSCtC9r/7/DBCG2qqUGPEgY TELvt+UMGyMP6ncNJH+vDEdHO4BBlSMzFQdj2sKyO3hOT5492cIOaT3gGokaDApL W913yqUkIfiUT6FUWJ6g4/LUt25pMG25Ednr/ZJJXR/pR+Ym3T3ytg+MSwRBmpEe +h26Q7qvd/p4f6VhTR0sEsxQfDLVXrEsj3kn0BL0rLklN5zH/bqmIsK2hio5Nl3H KBvbvyt+JbLhA/4+jygT6AygHDH9arpXWEh3ZcJVn7mE0OmPAvukdlLUj70K5F7r cCeMakcGBbSzit5tY7jUmSvkUewVBhAxAZmv1hgNnuCoSrGPtQZseCbM06cry+k= =TyKF -----END PGP SIGNATURE-----

6 10

Re: [tor-relays] OT: folding@home
by teor 27 Dec '14

27 Dec '14

Some thoughts on the security of crowdsourced computing: Installing additional software increases the attack surface of your relay, even more so when the new software access the network. (Not to mention any additional libraries.) There is also the issue of the security of automatic updates to the any executables - Folding@home may have less of an issue with this than BOINC, as there is only one project involved. If you're willing to accept the additional risk, it seems like a worthy cause. (There's also a minor additional power cost, which really only impacts your provider and the environment…) > Date: Sat, 27 Dec 2014 12:54:24 +0100 > From: mikael <mikael(a)gutanet.sk> > > Hi, > some years ago I contributed to https://secure.worldcommunitygrid.org/ > via BOINC (https://boinc.berkeley.edu/) but stoped. > Forgive my paranoia, but I couldn't find proof that it really helps what > they write, that the provided cpu power could doesn't land at NSA for > example :/ > > Any different experience? > >> On 12/26/14 6:55 PM, Sebastian Urbach wrote: >> Dear list members, >> >> I would like to invite any operator, who has some idle Cores (CPU or >> GPU) left,to join the folding@home distributed computing project: >> >> http://folding.stanford.edu/ >> >> There is now a brandnew team called Tor Project (Unofficial) with the >> id 227615. Hope to see some of you there :-) >

3 2

News reporting exit node attacks
by Austin Bentley 26 Dec '14

26 Dec '14

Anyone have any more information on any of this stuff? They claim it's a 0day but I have yet to see proof.

3 4

Possible DDoS
by Christian Burkert 26 Dec '14

26 Dec '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi *, I'm running a non-exit Tor node for a few months now on a virtual server hosted in a professional datacenter. That's the node: https://globe.torproject.org/#/relay/4C246EA9C950B872FD77F761CEAAB41D93D976… Yesterday, December 25th, the support wrote me, that my server is under a DDoS attack with 2GBit/s lasting over more than two hours. So, the hoster black holed my traffic to protect the other customers. The hoster wanted to know which services I'm running and told me that if I continue running Tor and further attacks will happen, then I would have to bear the costs. Eventually, I took down the Tor node to avoid further confrontation. Now I seek for your interpretation of this event: - - Has there been more recent incidents against Tor nodes? - - How can I investigate it? - - How should one react to a hoster? I mean they could have made up the whole thing... Looking forward to your comments Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCgAGBQJUnUdDAAoJEHAzZ6ooPDSy0nMP/1lyHPPFBxpAOvEiWL+ijrvA SPViJvZH/cPUS/11M7qm+bsZa/fbiRk6kY8ADcY8abe1Z8lHzMYPGwZvKaIijiZG M8hjCHtMWLipO6iLmVfFskDtRn37Ga2ibEhGkVesDV53kPcotgg4i7tIqIuNb11X Gnkk+WpYwkrS9nPZjYNLmce093s4lux/N5GyRY/gQii+h9mfDJ++W+1ueNU94UQ0 bvK1wF7MdicWlu0kR49hCgFtDFh7uUjP87MPZmmQYHI82qWhTJxqOuuImrnJew2k pCFSzn03x/hXg1QFNPNLsqHU9OhUob3/z17Azcpbir15mY4/YE7Gq14/LBM+FKh0 LqGjzaVbQo0hs0kE2yFk5sEP0Dsv5aiOUItqFIMTG52FYZ6cUh/eTxMd6vblHwfU ujil0rFCRqtmbF6wIDBuXDxc0fmdaRMWTDfSlPxYGkfUaq1tSea1OAvjFpheOcNM wu9QiTSq9BTLY010iHSYQDknSr+gFkc/ooNLsPV1AAZFyMlG0epLww6tqR7C9hZq RyEX9piqGal7mU56gETxhDrD0Z/aKgXMbS+KvYfZhopGWEVg5vbWPGxAId53nhr6 hjvLyFmy68hBdbOB/pvp8qvw8veQR3niiHIxhxAl+BIQzXX45x0uVCPHFUpbbLp5 POIwpEJ46oaz7+cddAHf =TcPt -----END PGP SIGNATURE-----

4 4

Re: [tor-relays] Possible DDoS
by Sebastian Urbach 26 Dec '14

26 Dec '14

On December 26, 2014 12:41:51 PM Christian Burkert <post(a)cburkert.de> wrote: Hi, > I'm running a non-exit Tor node for a few months now on a virtual server > hosted in a professional datacenter. Thank you ! > Yesterday, December 25th, the support wrote me, that my server is > under a DDoS attack with 2GBit/s lasting over more than two hours. So, > the hoster black holed my traffic to protect the other customers. I've seen this behaviour from some ISP's before and it's rather sad. If something like this happens my ISP is taking care of it without disabling my systems. I'm just getting a note with all the technical information and that's it. > The hoster wanted to know which services I'm running and told me that > if I continue running Tor and further attacks will happen, then I > would have to bear the costs. > Eventually, I took down the Tor node to avoid further confrontation. That's interesting, they gave you some infos like the time and the amount but nothing else ? Seems to me that they're pretty clueless and are fishing in the dark. Another reason for their behaviour could be that they want to get rid of you / your Tor node. Threatening customers is really sad, sounds like they heard the word Tor from you and then concluded "oh, than he basically asked for the attack". > > Now I seek for your interpretation of this event: > - - Has there been more recent incidents against Tor nodes? Nothing with that magnitude on my end for weeks. > - - How can I investigate it? You can ask your ISP for their logs regarding that attack. Do you have any logs on your system, maybe from a intrusion detection or anything else ? > - - How should one react to a hoster? I mean they could have made up the > whole thing... If you are already considering this than i would recommend changing to another ISP, sounds like there is already some distrust. > > Looking forward to your comments > Chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Icedove - http://www.enigmail.net/ > > iQIcBAEBCgAGBQJUnUdDAAoJEHAzZ6ooPDSy0nMP/1lyHPPFBxpAOvEiWL+ijrvA > SPViJvZH/cPUS/11M7qm+bsZa/fbiRk6kY8ADcY8abe1Z8lHzMYPGwZvKaIijiZG > M8hjCHtMWLipO6iLmVfFskDtRn37Ga2ibEhGkVesDV53kPcotgg4i7tIqIuNb11X > Gnkk+WpYwkrS9nPZjYNLmce093s4lux/N5GyRY/gQii+h9mfDJ++W+1ueNU94UQ0 > bvK1wF7MdicWlu0kR49hCgFtDFh7uUjP87MPZmmQYHI82qWhTJxqOuuImrnJew2k > pCFSzn03x/hXg1QFNPNLsqHU9OhUob3/z17Azcpbir15mY4/YE7Gq14/LBM+FKh0 > LqGjzaVbQo0hs0kE2yFk5sEP0Dsv5aiOUItqFIMTG52FYZ6cUh/eTxMd6vblHwfU > ujil0rFCRqtmbF6wIDBuXDxc0fmdaRMWTDfSlPxYGkfUaq1tSea1OAvjFpheOcNM > wu9QiTSq9BTLY010iHSYQDknSr+gFkc/ooNLsPV1AAZFyMlG0epLww6tqR7C9hZq > RyEX9piqGal7mU56gETxhDrD0Z/aKgXMbS+KvYfZhopGWEVg5vbWPGxAId53nhr6 > hjvLyFmy68hBdbOB/pvp8qvw8veQR3niiHIxhxAl+BIQzXX45x0uVCPHFUpbbLp5 > POIwpEJ46oaz7+cddAHf > =TcPt > -----END PGP SIGNATURE----- > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Sincerely yours / Sincères salutations Sebastian Urbach ----------------------------------------- Definition of Tor: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

2 1

Tor Weather doesn't register my fingerprint
by Giovanny Andres Gongora Granada 25 Dec '14

25 Dec '14

Hi, Today I decided to run a Tor Relay and contribute to Tor Project on a Rackspace that I have free for it. I want to use Tor Weather to get notifications about my relay, but when I try to register my fingerprint it doesn't accept it. What could be needed to register it? My fingerprint is: 4C90453B94DAC00BE356283F427CECE024B9D224 This is the info about my relay: https://globe.torproject.org/#/relay/4C90453B94DAC00BE356283F427CECE024B9D2… Regards, Gio -- Mozilla Hispano: http://mozilla-hispano.org Mentor en mozilla-hispano.org: Gioyik <https://www.mozilla-hispano.org/documentacion/Usuario:Gioyik> Mozilla Colombia: Miembro en MozillaColombia <http://mozillacolombia.org/our-contributors/> twitter: Gioyik <https://twitter.com/Gioyik> Blog: gioyik.wordpress.com irc: gioyik

2 1

iptables
by mikael 24 Dec '14

24 Dec '14

Hi, I don't know what to do. Please help. I'm getting the following warnings in arm: 16:13:15 [WARN] Your server (MY_PUBLIC_IP:9030) has not managed to confirm that its DirPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. 16:13:15 [WARN] Your server (MY_PUBLIC_IP:443) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. My iptables rules are: mike@host:~$ sudo iptables -nL Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 REJECT all -- 0.0.0.0/0 127.0.0.0/8 reject-with icmp-port-unreachable ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED REJECT all -- 62.210.140.93 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 62.210.151.213 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 103.41.124.106 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 103.41.124.112 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 109.230.220.135 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 115.84.179.148 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 117.21.225.176 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 188.116.19.109 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 219.232.239.40 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 221.235.188.214 0.0.0.0/0 reject-with icmp-port-unreachable ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:53 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:53 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:9001 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:9030 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpts:6881:6999 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpts:6881:6999 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 8 LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 5/min burst 5 LOG flags 0 level 7 prefix `iptables denied: ' REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable Chain FORWARD (policy ACCEPT) target prot opt source destination REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable Chain OUTPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

2 2

Whitelist
by Thomas White 24 Dec '14

24 Dec '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Directory Authorities, Can you please remove the following fingerprints/IP's from the blacklist as per my previous updates in tor-talk. D78AB0013D95AFA60757333645BAA03A169DF722 6F545A39D4849C9FE5B08A6D68C8B3478E4B608B 5E87B10B430BA4D9ADF1E1F01E69D3A137FB63C9 0824CE7D452B892D12E081D36E7415F85EA9988F 35961469646A623F9EE03B7B45296527A624AAFD 1EA968C956FBC00617655A35DA872D319E87C597 E5A21C42B0FDB88E1A744D9A0388EFB2A7A598CF 5D1CB4B3025F4D2810CF12AB7A8DDDD6FC10F139 1324EC51FBFA5FD1A11B94563E8D2A7999CD8F57 93CD9231C260558D77331162A5DC5A4C692F5344 IPs: 77.95.229.0/24 5.104.224.15 77.95.224.187 89.207.128.241 128.204.207.215 Authorities who haven't signed yet: gabelmoo tor26 maatuska moria1 urras Regards, T - -- Activist, anarchist and a bit of a dreamer. PGP Keys: key.thecthulhu.com Current Fingerprint: E771 BE69 4696 F742 DB94 AA8C 5C2A 8C5A 0CCA 4983 Key-ID: 0CCA4983 Master Fingerprint: DDEF AB9B 1962 5D09 4264 2558 1F23 39B7 EF10 09F0 Key-ID: EF1009F0 Twitter: @CthulhuSec XMPP: thecthulhu at jabber.ccc.de XMPP-OTR: 4321B19F A9A3462C FE64BAC7 294C8A7E A53CC966 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUmfi/AAoJEFwqjFoMykmDLpwP/iRLkxYXMGzW4ohr/sG2nvYX Fitv6242N0NuGEFkwZgjaYEdiab4Afdg5xacu5r3+tzdccKawZX9w7NOpx1w8iXS IxO4i/nU5DhA2hyn/67/J/JBOqjVY7V0nXVtEOAK3NUGjiRK+uaSojfZ/y3iXgvv MHdr5eGM5Rj7/sZ2eqLsCdzSr0atGQXxyz2JhlVim5rZfG9ikzvGcv8PbDl67Fgp e5l/aq3NAHv8EiMAML1Wpah+hi7fDuyX4QcSLfrrwK2sv+oetbPSa6Kue26PP2Fr UKQLB412hJ4gtLFL5LiQXWvs1cuQO4Yw7tBOJ3qsh4kWpDtVUD7OTIDZRCK+FkwF FuH2XHwN8IVhIcQcTZ+I7dKqWi9vMxaJPWi15osah5rW48ozqCCSqFO9xICOyMDH V1JSeHTVzWCKpkpocUYzIMJvjuqADtAyuR9CX0hgEgUdGf9kMYdo+zGsiXomHO02 1iuWsq1HjwNxL2nAZJpCNsNetcHSvRtwGXbWx2Fr6P/T3tBh7gYfTSD2KwNnw+yE X0IDz5J02Xqz1nU2kiKr+IkZDXI+0aKzkD0KI6Uia0LEcZmjKNEePccHd+PcwIY/ YnH55rVyilUsLBvgQKZwGBVk+9kNmXjwiH1JJbUrGcfsCvZb+E05n5WMcbNYRwW2 N+2CQDnmN8aHLErrs5RU =zOpP -----END PGP SIGNATURE-----

2 1

help needed to setup a bridge on amazon and relay on PC
by Sasikantha babu 24 Dec '14

24 Dec '14

I've been trying to setup a bridge on amazon cloud and relay node on PC but never succeeded in setting it up. I always get an error "Your server (IP:9001) has not managed to confirm that its ORPort is reachable". 1. My PC is behind netgear router and I had configured portforwarding (portforwarding seems to work but tor-relay fails complains about ORPort reachability). 2. Follow the steps https://cloud.torproject.org/#get_started and created an instance on amazon cloud but facing the ORPort reachability. Dec 23 14:19:37.000 [notice] Bootstrapped 5%: Connecting to directory server Dec 23 14:19:40.000 [notice] We now have enough directory information to build circuits. Dec 23 14:19:40.000 [notice] Bootstrapped 80%: Connecting to the Tor network Dec 23 14:19:40.000 [notice] Bootstrapped 85%: Finishing handshake with first hop Dec 23 14:19:41.000 [notice] Guessed our IP address as ip (source: ip). Dec 23 14:19:41.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Dec 23 14:19:42.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Dec 23 14:19:42.000 [notice] Bootstrapped 100%: Done Dec 23 14:19:42.000 [notice] Now checking whether ORPort IP:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) Dec 23 14:39:41.000 [warn] Your server (IP:9001) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Thanks

2 3

Tor Relay Operators Meetup at 31c3 *moved* - 28.12. 13:00
by Moritz Bartl 23 Dec '14

23 Dec '14

Hi, I had to move the meetup slightly in time and to a different room. I was told by CCC orga that they need the original room for Engel meetings. NEW DATE: 28.12.2014 13:00 LOCATION: HALL C https://events.ccc.de/congress/2014/wiki/Session:Tor_Relay_Operators_Meetup See you! -- Moritz Bartl https://www.torservers.net/

1 0

Tor Relay Operators Meetup at 31c3 - 28.12. 14:15
by Moritz Bartl 23 Dec '14

23 Dec '14

Hi, Torservers.net invites Tor exit relay operators and organizations to a meetup. If possible/relevant, for example if you're a member of one of the 'Torservers partner organizations', please prepare some slides on your activities. You're obviously also welcome to suggest sessions as a member of the broader relay community! We will do quick presentations on recent and future activities around Torservers.net, talk about events relevant to the Tor relay community, and what lies ahead. https://events.ccc.de/congress/2014/wiki/Session:Tor_Relay_Operators_Meetup 2014/12/28 14:15 - 16:15 See you there! -- Moritz Bartl https://www.torservers.net/

5 8

DDoS attack targeted on my exit node
by Michael Renner 22 Dec '14

22 Dec '14

Hi, my tor exit node was targeted with two DDoS attacks, one on 2014-12-20 01:00 CET and one on 2014-12-22 18:00 CET [1], both lasting about 5 minutes each. This alone wouldn’t be too noteworthy if it weren’t for the fact that a) there’s a certain state of alarm WRT the Tor networks integrity and b) these are the only attacks my ISP has on record for the over 2.5 years of operating the Tor Exit node. If no other operators have noticed anything out of the ordinary (given by the silence on the list) this is most likely a fluke (getting rid of pesky IRC users?), but better be safe than sorry. best, Michael [1] http://i.imgur.com/Zu9UkW3.png <http://i.imgur.com/Zu9UkW3.png> Summary screen

3 2

ntp needs attention
by Felix 22 Dec '14

22 Dec '14

Hi See: https bugs.debian.org/cgi-bin/bugreport.cgi?bug=773576 Debian will be fixed by 'apt-get update' and 'apt-get upgrade'. dpkg.log tells if the fix is in place: https security-tracker.debian.org/tracker/CVE-2014-9293 ... Cheers!

3 2

Hibernation and Guard flag
by Filippo Valsorda 21 Dec '14

21 Dec '14

Hello, I set up a relay node on my VPS to eat up all that unused bandwidth, and it's doing well so far [1]. Since I have ~3TB per month and I heard hibernation is preferable to throttling, I set up monthly accounting with that cap. However I have two doubts: 1. Is daily accounting preferable? That is, what's best, shorter or longer hibernation periods? 2. How does hibernation play with the Guard flag? I know Guards rotation plays a crucial role in users privacy, and it seems to me hibernation would really hurt a client that selected you as its Guard, since it will have either to run with one less available Guard, or pick a new one and increase its risk. Also, I know there are talks about making only 1 Guard selected, how would that play with hibernation? N.B. please cc me into the replies, I might not be getting only-in-list replies. Thanks, Filippo [1] https://globe.torproject.org/#/relay/2EC042F4274CC8A54381C78E8D1BF322FA26A0…

2 1

Re: [tor-relays] Platform diversity in Tor network [was: OpenBSD doc/TUNING]
by teor 16 Dec '14

16 Dec '14

> From: Richard Johnson <rdump(a)river.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Platform diversity in Tor network [was: > OpenBSD doc/TUNING] > > On 2014-11-05 10:47, Libertas wrote: >> I appreciate your interest! Also, I hope I'm not speaking with too >> much authority. If anyone here has more OpenBSD experience than me, >> please send addendums or corrections. > > Maybe call this an addendum? Some version of the following work in progress > is going onto our local documentation store for others maintaining our > OpenBSD relays. > > It's a bit long-winded for inclusion in doc/TUNING per > https://trac.torproject.org/projects/tor/ticket/13702 , as it's intended to > educate *BSD and Linux sysadmins about a smidgen of the why behind the > tuning recommendations, as well as point at further exploration. > > > Richard > > ------- > Our OpenBSD tuning for Tor involves: ... > 4) Probably running more than one relay on a host to use available CPU > cores and bandwidth. ... > 4) Loading more CPU cores > > If you have one of your CPUs maxed out running a Tor relay, with the other > CPU(s) mostly idle (see top(1)), yet you have bandwidth to spare still, you > can run additional Tor instances to sop some of it up. > > The sanest way to handle this is to make each relay a stand-alone entity > with a naming scheme to keep them straight. Here, we'll use "tor#" for every > relay past the first. > > Make per-relay directories in /var owned by _tor:_tor mode 700 > drwx------ 5 _tor _tor 512 Jan 13 18:52 /var/tor/ > drwx------ 5 _tor _tor 512 Jan 13 22:39 /var/tor2/ > drwx------ 5 _tor _tor 512 Jan 13 22:39 /var/tor3/ > ... > Copy the tor startup script /etc/rc.d/tor to match the naming scheme. > /etc/rc.d/tor2 > /etc/rc.d/tor3 > ... > Copy the torrc from /etc/tor/torrc. > /etc/tor/torrc2 > /etc/tor/torrc3 > ... > Modify /etc/tor/torrc2, /etc/tor/torrc3, ... so they refer to their > appropriate private DataDirectory and PidFile, listen on the appropriate > ports and IP addresses, and have the appropriate exit policies. (Remember > that the public Tor network will by design ignore more than two relays per > IP address.) > DataDirectory /var/tor2 > PidFile /var/tor2/pid > ControlPort 9222 > Address 10.2.2.2 > ORPort 8222 > DirPort 7222 > ... > DataDirectory /var/tor3 > PidFile /var/tor3/pid > ControlPort 9333 > Address 10.3.3.3 > ORPort 8333 > DirPort 7222 > ... > Set each relay to launch at system startup via the named /etc/rc.d scripts in > /etc/rc.conf.local's pkg_scripts. > tor_flags="${tor_flags} -f /etc/tor/torrc" > tor2_flags="${tor2_flags} -f /etc/tor/torrc2" > tor3_flags="${tor3_flags} -f /etc/tor/torrc3" > ... > pkg_scripts=" ... tor tor2 tor3 ..." > Set openfiles-max for each named pkg_script from /etc/rc.conf.log in > /etc/login.conf. > tor:\ > :openfiles-max=8192:\ > :tc=daemon: > tor2:\ > :openfiles-max=8192:\ > :tc=daemon: > tor3:\ > :openfiles-max=8192:\ > :tc=daemon: > ... > Remember to allow inbound traffic to the additional ports set in > /etc/tor/torrc[#] in your /etc/pf.conf. Why give advice on "tor3" when the current consensus parameter for limit per IP is 2? In case someone has an extra IP? Or are you hoping we will increase the consensus parameter to 3? I could revive that suggestion, by the way - it stalled as trac #13414 due to concerns with making sybils easier. https://trac.torproject.org/projects/tor/ticket/13414 Maybe we could try for 3 per IP? teor pgp 0xABFED1AC hkp://pgp.mit.edu/ https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 http://0bin.net/paste/Mu92kPyphK0bqmbA#Zvt3gzMrSCAwDN6GKsUk7Q8G-eG+Y+BLpe7w…

2 1

Platform diversity in Tor network [was: OpenBSD doc/TUNING]
by grarpamp 16 Dec '14

16 Dec '14

On Tue, Nov 4, 2014 at 12:25 PM, Libertas <libertas(a)mykolab.com> wrote: > I think it would be a good idea to add OpenBSD to doc/TUNING because [...] > promoting OpenBSD relays benefits the Tor network's security. Absolutely. Not just due to OpenBSD's security positioning, but moreso from network diversity. Windows is its own world. But if you're a Unix admin there's no reason Linux should be deployed 20x more often than [Free/Open]BSD. It's ridiculously counter to meeting diversity goals, especially with bandwith weighting if one platform is getting grossly disproportionate traffic than another. Just pick one of the two BSD's and run it instead. FreeBSD in particular is well suited to the OS and network needs of Tor. And knowing how to admin more Unixes will serve any admin well. 5950 Linux 1593 Windows 173 FreeBSD 55 Darwin 44 OpenBSD 7 NetBSD 6 SunOS 4 Bitrig 2 GNU/kFreeBSD 1 DragonFly

12 29

Out of memory message
by Logforme 15 Dec '14

15 Dec '14

I run the relay Logforme (855BC2DABE24C861CD887DB9B2E950424B49FC3). Yesterday I saw new messages in the log file: Dec 06 09:28:13.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 06 09:28:16.000 [notice] Removed 1040388096 bytes by killing 1 circuits; 14631 circuits remain alive. Do I read that correctly as one circuit using 1GB of memory? Here's the first lines from the top command: top - 09:40:41 up 31 days, 1:51, 1 user, load average: 0.53, 0.62, 0.66 Tasks: 95 total, 3 running, 92 sleeping, 0 stopped, 0 zombie %Cpu(s): 10.2 us, 2.0 sy, 0.0 ni, 83.2 id, 0.0 wa, 0.0 hi, 4.5 si, 0.0 st KiB Mem: 3950828 total, 3833092 used, 117736 free, 49696 buffers KiB Swap: 3212284 total, 1296392 used, 1915892 free, 99168 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2680 debian-t 20 0 4134m 2.8g 24m R 63.5 73.4 27199:00 tor The relay is running on a dedicated debian box with 4GB of ram. It usually only uses about 0.5GB but now it is maxed out. The relay and the box is so far working fine, I just wonder if this is some kind of attack or if anything is wrong and if there is anything I should do about it.

5 8

Changing ulimit for debian-tor
by Lluís 12 Dec '14

12 Dec '14

The limit to open files is set to 1024 by default in my system. So it is for the "debian-tor" user, too. It seems to me a bit low. I tried to rise it a whit through "sudo" and getting a shell for debian-tor, but it doesn't work. Can I use PAM-LIMIT with tor ? If not, how can I set ulimit for debian-tor when booting ? And when restarting tor ? BTW, may the open files ulimit preclude a relay to get the "guard" flag ? thanks in advance, Lluís Spain

5 6

specifying your own entrance and exit nodes
by Seth 10 Dec '14

10 Dec '14

Assuming there are certain Tor notes being run by parties hostile to my own interests, what are the pros and cons of specifying one's own list of trusted entrance and exit nodes? I run a Tor relay at home 24/7 and use that as my entrance point. I do this to provide cover traffic for my own Tor use as well as help out the network. I also try to use Tor for all my daily web browsing when possible. This has given be a lot of headaches. Besides the demoralizing barrage of Cloudfare captchas, I've had a lot of problems with dropped connections, timeouts, SSL cert warnings, fatal errors connecting to HTTPS sites. I started to get a gut feeling, warranted or not, that some exits nodes might be meddling with my traffic. To combat this I changed the configuration on my local Tor relay to use only exit nodes run by organizations or people that I felt I could trust. I didn't bother with specifying entrance nodes because I could not see what the gain would be. This seems to have curbed some of the problems, with the tradeoff that responsiveness is much more inconsistent. I'm just curious if restricting exit nodes to a few dozen that you trust effectively defeats most of the purpose of using Tor. What would be the bare minimum of Tor exit nodes a person would need to use in order to make life difficult for the Panopticon surveillor scum? If this post is more appropriate for Tor-talk, please let me know

3 3

Re: [tor-relays] No obfs3 traffic at all on bridge
by TheGreatWent 09 Dec '14

09 Dec '14

From: Marco Gruß<tor-relays(a)email.todmue.de> > Hello, > > my obfs3 bridge has now been up for > 20 days. > > I have iptables rules in place to count packets. To date, > I have not seen a single packet to either the obfs3 or > the scramblesuit port. Both are working though, I just > tried them with the Tor Browser. > > Is this a good sign (i.e. the bridge is still in reserve) > or a bad sign (something's wrong)? > I set one up around the same time and haven't seen any traffic either. Maybe there is a surplus of them? I couldn't figure out what the different bridge pools were or how they got allocated to them.

1 0

exit policy to reflect country-wide ban
by Vladimir Ivanov 07 Dec '14

07 Dec '14

hi. Recently, github was blocked in Russia (see discussion here: https://news.ycombinator.com/item?id=8692584) The ban is executed by all major ISPs (comply with this regulation is necessary to keep the telecom license so no ISP is risking to disobey), this means that if your exit node happens to be in Russia, you're out of luck when you try to connect to github. Some suggest marking exit nodes in Russia as bad exits because connecting via them leads to various problems (like node provider doing MitM on all github https connections). Here is an example: https://twitter.com/wiretapped/status/539934125293961216 I think, if Russian exits operators implement reduced policy rejecting github, that would be better solution: they're still usefull for all other sites and a client would access github using a tor exit elsewhere. Do I miss something here? Are any disatvantages of this? More general, if a network, a particular exit node is connected to, blocks some IP addresses, is it wise to reflect those changes in the node's ExitPolicy? BR, Vladimir

4 5

No obfs3 traffic at all on bridge
by Marco Gruß 07 Dec '14

07 Dec '14

Hello, my obfs3 bridge has now been up for > 20 days. I have iptables rules in place to count packets. To date, I have not seen a single packet to either the obfs3 or the scramblesuit port. Both are working though, I just tried them with the Tor Browser. Is this a good sign (i.e. the bridge is still in reserve) or a bad sign (something's wrong)? Thanks for any help! Marco

1 0

According to globe and atlas, bridges have guard flags, while they actually don't have them at all...
by Justaguy 07 Dec '14

07 Dec '14

What is the cause for this behavior? https://globe.thecthulhu.com/#/bridge/286FD249840142D1C7536C2D12FDBE5EA63AD… https://atlas.thecthulhu.com/#details/286FD249840142D1C7536C2D12FDBE5EA63AD… -- Contact: Irc, justaguy @ Freenode or OFTC OTR fingerprint: FF6D1AC2 13F38B15 EDB21522 D3530A6F 6EE01996

2 1

Re: [tor-relays] Guard flag and some irregularities
by Sebastian Urbach 06 Dec '14

06 Dec '14

On December 6, 2014 9:41:34 PM Rafael Rodriguez <rafaelr(a)icctek.com> wrote: Hi, > https://atlas.thecthulhu.com/#details/48ADFCC561402D7EBB1CDE233F206B01D8FA0… > > > 1- Is it ok for the Guard flag to come and go so often? I do not see > anything wrong with my relay and it is pushing up to 12MBs at times. >From what i can see the numbers are way lower than that. Recently the criterias to qualify as a guard changed, i assume that you drop out of the guard position because you don't make the cut all the time. If im not mistaken the number of guards dropped roughly 50 % after the changes were implemented. > Most of the time, my relay pushes between 3-7MB/s constantly and that's > fine. But there are occasions in which I see it spike and send out as > much as 12MB/s I'm struggling with the numbers, if you take a look at the graphs you are not getting this much traffic. Maybe your system is under attack (DoS, DDoS) ? It does not look like it's regular Tor traffic ... -- Sincerely yours / Sincères salutations Sebastian Urbach ----------------------------------------- Definition of Tor: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

2 1

Guard flag and some irregularities
by Rafael Rodriguez 06 Dec '14

06 Dec '14

https://atlas.thecthulhu.com/#details/48ADFCC561402D7EBB1CDE233F206B01D8FA0… 1- Is it ok for the Guard flag to come and go so often? I do not see anything wrong with my relay and it is pushing up to 12MBs at times. Most of the time, my relay pushes between 3-7MB/s constantly and that's fine. But there are occasions in which I see it spike and send out as much as 12MB/s when I have set a limit of @6MB/s. 2- Is Tor not respecting the limits? If it doesn't respect the limits consistently it might as well overkill my budget which translates into me killing the relay.

2 2

Running a New Relay
by Abhiram Chintangal 06 Dec '14

06 Dec '14

Hello, About two days ago, I started running my first tor relay using a digital ocean vps instance. Yesterday, I found this nice article[1] about the life-cycle of a tor relay. It was a great read and I think I understanding of how tor works has improved quite a bit. Currently, my relay[2] whose up-time is roughly 2 days 18 hours doesn't have any active circuits ( via tor-arm). Since its in the unmeasured phase( days 0-3) shouldn't it be making circuits back to itself? I believe the number that was mentioned in the article was four. I apologize if my question seems silly. Thanks! -- Abhiram Chintangal I guess we agree with reason, but now it's a matter of disposition [1]https://blog.torproject.org/blog/lifecycle-of-a-new-relay [2]: https://atlas.thecthulhu.com/#details/0D63999A202B34EF1CD9669BC45B0A697D9BF…

2 1

Atlas slow/not working?
by Abhiram Chintangal 06 Dec '14

06 Dec '14

Hello, I am not able to check my relays status via Atlas for the last two days. Any ideas? Thanks -- Abhiram Chintangal I guess we agree with reason, but now it's a matter of disposition.

5 5

ArchWiki article about fast relay configuration
by usprey 06 Dec '14

06 Dec '14

Hi List I have written my own notes into https://wiki.archlinux.org/index.php/Tor#.2B100Mbps_Exit_Relay_configuratio… . All and any feedback will be appreciated! Are there any privacy concerns about using pdnsd to cache DNS locally?

1 0

Planning a relay
by TT 06 Dec '14

06 Dec '14

I'm thinking of running a relay, and i've a few questions regarding the requirements and the general setup. So far this is just planning. The hardware would be clean and in my possession, but the connection would go through a Swedish-based VPN provider because i'm not interested in running it through my own IP address. The provider endorses Tor and places no limits whatsoever on the services run through their connection, has port forwarding and allows exits, so no issues there. They also have a strict no-logging policy, but words are cheap so you never know. I guess the first question should be whether such a relay would be welcome on the Tor network in the first place? I am aware that connecting to Tor through a VPN isn't generally recommended, but what about running a relay through one? Better idea, or a ridiculously bad one? Second, while it would run on a (nearly) dedicated 100mbit connection, i do not have dedicated equipment. The machine needs to be taken offline between every 2-4 weeks, for some days at a time. Frequent OS updates also often require reboots in addition to this downtime. So much for a stable flag, but more importantly i need to know if this behavior is undesirable for running middle/exit relays? If so, would a bridge be better suitable with the tools i have at hand? Third, regarding running bridges. The Tor Project FAQ states running your own bridge might improve your own anonymity. I assume this means you would manually set up your TBB to connect to *your own* bridge, is this correct? And finally, since the bridge would run on a separate (VPN) IP address, would this make a difference (re:anonymity) for better or worse if you connected through it yourself? I'm likely missing something here because it seems it would basically be the same as simply connecting to Tor through the VPN client alone. Thanks.

7 9

Tor Server - DDOS or High Load
by webmaster 04 Dec '14

04 Dec '14

Hello Folks, I'm running a relay tor server since several years. Last week (24 Nov) I noticed a high load on the tor server (cpu load 100%). After some investigation i found out that tor causes the high load. After killing the process the load decreases to a normal level, but after restarting the tor process again the load increases again. Arm log: Could not open "" for writing: To many open files. or Failing because because we have 1017 connections already. Please raise your ulimit -n Tor's file descriptor usage is at 91%. If you run out Tor will be unable to continue functioning. At first I thought: Fuck, someone intruded into my machine. But after some looking through Arm I found many (>100) INBOUND connections. After one hour and some iptables tuning the cpu load decreases. Could the high load caused by an attack on my machine or is this just some small load peak? Hope for some reply -- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (MingW32) mQENBFHMmT8BCAC0smvU7Bq1ABxAhvBRn7d4ekkk95aCE4TTQo4wy1z/rGLhQfdt dhiD+Vy61vGrsdK3ei5sW6rBvX2m8+YmBi+8AAgSiZmS0JM3Zz3cmTi5oh0D/yM8 4aDj7wQYfJyzSmYN8InAQ5eA77lwIdqG27kR9wga2szeJwCnWReta0R+7YFkpUW+ zUlf4SWcUx5SmBsaiELQpm+Qcn+fyopo12RX6YVmoNPBvN2nDXDnRhUCKGc+0xhD UrBpCHrApK6sTnMsD34ClCLTL2L1gckQ0AsQqY3PJlx3R8kIJxlmr6R3WnjPMIG0 lqrukB9PcOrHM1MZXK1gK6AtypHBN98lr8Z9ABEBAAG0KndlYm1hc3RlciA8d2Vi bWFzdGVyQGRlZmNvbi1jYy5keW5kbnMub3JnPokBPgQTAQIAKAUCUcyZPwIbIwUJ CWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQcN1vxvRQl+0SEwf+KXjf YtiSUSVS11uqeQ/8g46NwmNa91P3toZvEd7vhLSbjnL9bi/vApzNnUTGT3VP4/NA dg9SbR4qKlSr8T+YikRMV3tiuiVq8m7g00qM9y8MIomwJTounz8VdO/aJXFSOxAK Bb6ElREADspCzr2qSZCnozWUzbd+b8owbGeRRq3e33Aa5Nlm/xDRxGDWANbaIA8q Gkibvy3vWEwrxiwsakvHGaEZnPEtlNm3M1xcmFAuyl73qzUMkLN0u9E/2igo4EB5 EdMb5Ab5hfWdljxBqJr0tsvMfSK4VkzMCbKYkTqHZIRPQnhiSBE6Yo1Q6RCl/Hht bkvU4RA0J+NkXMZljrkBDQRRzJk/AQgA0HojJnK0uhEkAnbmszYsf477DV+LD02s ZEAlLGhJlf9qYaDiPMPwaZ3nK8/PYKzPpBWfHgRQP97rLHPIVJYl3BHDa/nWeZ2b e/HzYhpX0djbK9qe6W/CTfGbXmC/y+4dDGB8dvtTAW3JILm7xEdwiWtywozEVy7V lnMK4JQvlfOh+3XO6qv71FXyuRkObvkYzqvxUYHewtvvObcVxXHP0C0O6LB44iAW 2boZVVuiHdudnyNAezJajPMUT8SnI0bwL6+0TgnHL4cKNUEPQljIrrvi+9nCkq7V uBtnsYtyoo2reoxmCbX/Z1zZsxdUcKpeJHlc5AypyN8DUJ+APJ9NnwARAQABiQEl BBgBAgAPBQJRzJk/AhsMBQkJZgGAAAoJEHDdb8b0UJftOY0H/1TChmQrJC/qzefW PK7EqFlBg3TIEXdu8JHjF42ZOgzQRfp7E2wWzEx0Y45lNXMs6Yg15hWCEDaUDF6F 5WZKNrP8xIldyR9Aw7fyKqjZ9UuKovqofHsCiaSO7nWzGM6GF3nBDNI9NcFve/wN wggyjAbohOJrJGal3N0HlG3cakqjEmjBe1gQEMC0ZPlWstb/cqqr49TNPrRmQc4P SyGffh8Xqhw94m1LDBXFEaYe7AxjNk1sPAVfO1rOdLF6GOun/UwgbhDQX/Rb9C3t AhjSgyFEiR/gfrUZ7R6SY51qOUf1lN5ZN85C/x27XoZWYlsNaH3Ei6nG+yeswBMk ZRMbezQ= =Med3 -----END PGP PUBLIC KEY BLOCK-----

5 9

high amount of IOERRORs of closed ORconnections
by Toralf Förster 04 Dec '14

04 Dec '14

I still do wonder about the high percentage of IOERRORs of closed ORconnections (as seen in page 1#5 of the arm tool window, press e + q). May I ask here others about their experiences ? The issue is already filed in [1]. [2] contains a python script I used to monitor the issue directly (instead using arm). [1] https://trac.torproject.org/projects/tor/ticket/13603 [2] https://trac.torproject.org/projects/tor/ticket/13603#comment:10 -- Toralf pgp key: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 0076 E94E

1 0

Colocated relay pricing
by grarpamp 04 Dec '14

04 Dec '14

What are you seeing as prices to colocate, in terms of: 1RU - rent, power, etc IP's - a few (3, or up to a /29 ie 8-3=5) Bandwidth - In terms of $US/Mbit Colocation Country/State. Company.

3 2

Why isn't there an announcement of the new Tails?
by I 03 Dec '14

03 Dec '14

1 0

doc/HARDENING Draft
by Libertas 30 Nov '14

30 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I thought I'd share an initial draft of doc/HARDENING. Please share any opinions or contributions you have. This was written in a little more than an hour, so it's still a work in progress. However, in the spirit of prototyping before polishing, I thought I'd share early. Here's the relevant ticket: https://trac.torproject.org/projects/tor/ticket/13703 A specific topic of conversation is how much of the advice should be in the document itself as opposed to linked sources. It could also use more OS diversity. After reading it, you can probably guess which *nix flavors I'm familiar with. Enjoy, Libertas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUc7qtAAoJELxHvGCsI27NOwsP/1bP+g4W2y1NHefR5bd+5hwo V927TXzarNneNFxfhKJsVewVnU593Ex13iHv+WgA+XM39xiK8KkhpxOaw2IpahZp pIRCk4/XX78YaEc/K3ci2AsNGFVXPBX7nm4/VOZ5qiGfo+FVeipykweF1dF+X1Wc 1wr8Q9LWKoIab+klu/BG5nG5NtwICYslbgXMvNnapHuy0Xn1+fvBx3mW9teMkJ0N Npssiy7XUqJx1XpdYNJr4XI28aHOV2p4FeCdsAgaQ1OBkOvpzMd+fw2Yb3FOiX/l 5pNCPMXFsS/+OXp1qOFKDQoOb7fEP6mY4NqdSovuJU0oWdurnHVk/X3SidALfH/L vFPdTwpCJSMLuYO7HsLLiLx6LkDtrDZ2y9+tUfpqKGAN0upXrIi5GWsbUeLcCqwY UFYdSg1GHsWJz7fU6F1vDLpGsiXU5yVqgaxfP06+nZ/smRt5sA3nlMDCZJi3BDes k0+c4+tAPZ5Yt6kJ5b1GBgxQMokDqnLm/4pb/qlp0EzDfhWpA+Un2lGdvInrz1ds VsVvbq/LLuxYylC3hlF8pNxBVMdbXycWM1w/VHtDjPZFdo9AO4CJHXeShYQa2O0W cBXdU+O59wWoxiCuEfo0O2xaJw2UIRfxauQbcp/A0rg8FKU1c2QeP2t7y8VdVC1Y SgQNVCUKYPBMCywJw9PA =yY3r -----END PGP SIGNATURE-----

9 14

Fast Exit Node Operators - ISP in US
by SiNA Rabbani 29 Nov '14

29 Nov '14

Dear Relay Operators, I noticed there are very few US based exit nodes in the network. And more and more people are jumping on the same set of AS numbers in Europe. I am not if the reason is lack of Tor friendly ISPs or people are just too freaked out about the summer of Snowden. I think it's very wrong to assume that EU countries are not part of the world-wide-wiretap, packets are going through a few internet exchanges anyways. I have been hosting/operating Faravahar (one of the authority directory servers) at Rethem Hosting (rethemhosting.net) for a couple of years now, and never had any issues. I also just brought up 2 exit nodes there: https://atlas.torproject.org/#details/A5B1C342B316C2AE5695B903CED18F619A836… https://atlas.torproject.org/#details/6FFCDF910C32D620FCC6EEF7A8A57F3E9A234… If anyone is interested in running fast Tor Exit nodes at Rethem Hosting. Feel free to contact me directly, so I can make proper referral/introductions. Rethem Hosting is also able to provide hosting In IceLand, but you get the most bang for your buck in the US datacenter. Thank you for contributing to Tor. All the best, SiNA # Consensus Weights Advertised Bandwidth Guard Probability Middle Probability Exit Probability Nickname Fingerprint Exit Guard Country Autonomous System 1.5958% 0.0000% 0.0000% 0.0000% 4.8946% (11 other relay groups) 17.6751% 0.0000% 0.0000% 0.0000% 54.2124% (total in selection) 1 4.1722% 0.0000% 0.0000% 0.0000% 12.7968% * (26 relays) (26) (22) FR (4) 2 3.8256% 0.0000% 0.0000% 0.0000% 11.7338% * (19 relays) (19) (16) DE (6) 3 2.1098% 0.0000% 0.0000% 0.0000% 6.4712% * (10 relays) (10) (8) NL (6) 4 1.4620% 0.0000% 0.0000% 0.0000% 4.4843% * (5 relays) (5) (5) RO (1) 5 0.9090% 0.0000% 0.0000% 0.0000% 2.7881% * (6 relays) (6) (5) SE (4) 6 0.8788% 0.0000% 0.0000% 0.0000% 2.6955% * (4 relays) (4) (4) CH (2) 7 0.8560% 0.0000% 0.0000% 0.0000% 2.6255% * (3 relays) (3) (3) LU (1) 8 0.6510% 0.0000% 0.0000% 0.0000% 1.9967% * (1 relays) (1) (1) LR (1) 9 0.6433% 0.0000% 0.0000% 0.0000% 1.9731% * (10 relays) (10) (8) US (10) 10 0.5715% 0.0000% 0.0000% 0.0000% 1.7528% * (2 relays) (2) (2) GB (1)

17 40

Re: [tor-relays] Fast Exit Node Operators - ISP in US
by teor 23 Nov '14

23 Nov '14

> Date: Sat, 22 Nov 2014 17:58:37 -0800 > From: Seth <list(a)sysfu.com> > ... > > I should have also mentioned in my previous post I put the following in > /etc/tor/torrc > > # Bandwidth and data caps > AccountingStart day 19:45 # calculate once a day at 7:45pm > AccountingMax 33 GBytes # 33GB X 30 days = 10GB shy of 1000GB/mo. > RelayBandwidthRate 3000 KBytes > RelayBandwidthBurst 3750 KBytes # allow higher bursts but maintain average There are 7/12 months that have 31 days, where your 33GB per day will result in a (potential) 23GB overuse. (And that's not including non-tor traffic like OS updates.) Why not use 32GB x 31 days = 992GB, or 31GB x 31 days = 961GB ? teor pgp 0xABFED1AC hkp://pgp.mit.edu/ https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 http://0bin.net/paste/Mu92kPyphK0bqmbA#Zvt3gzMrSCAwDN6GKsUk7Q8G-eG+Y+BLpe7w…

3 2

(no subject)
by Chris Boyd 22 Nov '14

22 Nov '14

http://estudiohalabi.cl/problem.php?4z0oxj4vkg5 wodencafe wodencafe(a)gmail.com +++++++++++++ Penalty for premature evacuation. -- Reality Bites

2 1

wild swings in Advertised Bandwidth
by jchase 22 Nov '14

22 Nov '14

Hi, I'm running a low-volume bridge on a raspberry pi. Globe.torproject says that my fingerprint is 1BCD3EBEFE17EEB86EEDE21D5E2DB8468E2864CF . I'm keeping an eye on myself and traffic via globe.torproject and my advertised bandwidth makes wild swings: one day its 56 kB/s and the next day it's 8 kB/s. When I read that "The minimum BandwidthRate setting is 20 kilobytes per second", I am confronted with the fact that 8 is less than 20 and it doesn't seem worth it keeping my bridge up and working. Why would a bridge make such swings in advertised bandwidth? And is there any good reason to keep the bridge up and working if it sinks to 8 kB/s? Thanks, J Chase

2 1

Decision on Dedicated Server for Exit Node
by Libertas 22 Nov '14

22 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I've been looking for a budget dedicated server to host an exit node on, and the best option I've found is BalticServers. However, they're already listed on the GoodBadISPs wiki page, and because they're in Northeast Europe (Lithuania, to be precise) I'm concerned that their ISP already has more exit nodes than is healthy for network diversity. Is it a good idea to host another exit node there? If you think there's a better option, I'd appreciate it if you could tell me either publicly or privately. Thanks, Libertas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUb8qfAAoJELxHvGCsI27Nx0sP/j5wBhV7EJZZ4EJoPgnoEH8A i6cDB3sL+Q50MgZivZLG47U+wdj95EJeIRl16RsaL0JaShVwyvbpStaIuhpOoujX FN0oumg3Z27fists+CSImLAHHHyr3a526XbWQazKZ7ReBvBZeIOa4PKA/OWsI8wg CWogwEWxbVNMojWaHMID3Y43qEeSH/T0R9ibqyrvqoZrOhnVqH1+1HzVs4FAWoST UMS2m/+b1qL4riL20XyaS0SUO0OkNbL3ecBnCN9LZJwMMuXVB4QNrsBSNFtDTpeu r8ZPJ/DxLJuQOtOvluSqqriKZCCi2lFAHovcXAf2ele0xqPrnJLFXDvhKkuAlv2o wQb+hdpBZ95u073cu/md8vTYVzA8NJ/sRTPmsWtxdRR8PMVpx59+BOAWNYMLWgEu JdTVinsbaWuKKTCtsZY0KAmYRbYC8E0O46z3OnOaeLX2s4MLUK/rPV3FoOAJ0tA3 ixnJ0kjuaFiBN7SRn+N4imBEmt5DP3cbPmai6YX5FzaL0RjlD+1uWk/ZxV66iK3c YrisgQ0bWFbVCGeztblvBGQF3o6cElCJ26Cvy3EaTn7No+1d4f+/1rYwYCmNHjYY mdfUhSfWWFNv+oaF9MU/IHek45l+yrTHHZlhrk3pmFX/bcUWWcfcYX1D/aMhgH58 7p48+5liXZOtSuVK44aS =/fUH -----END PGP SIGNATURE-----

4 4

Website no longer available from Tor
by Marcello Vitagliano 22 Nov '14

22 Nov '14

Hi from a few weeks the site spacemarc.it is no longer accessible via TOR. My hosting does not apply any filter nor I do it from code. I do not get any error from web server (forbidden, timeout and so on...) but the Tor Browser (v4.0.1) simply tries to connect for several seconds but to no avail (try yourself please). I checked the Apache logs and I do not see any request from an IP Tor. In your opinion why is not it more accessible? Thanks

3 3

building Tor against LibreSSL 2.1.1 fails with "undefined reference to `EVP_aes_128_ctr'" error
by Seth 22 Nov '14

22 Nov '14

I'm trying to build tor-0.2.5.10 from source against LibreSSL 2.1.1 on a FreeBSD 9.3x jail system. It fails with this message ----------------------------------- CC src/tools/tor-gencert.o CCLD src/tools/tor-gencert src/common/libor-crypto.a(aes.o): In function `aes_new_cipher': /usr/local/src/tor-0.2.5.10/src/common/aes.c:100: undefined reference to `EVP_aes_128_ctr' *** [src/tools/tor-gencert] Error code 1 Stop in /usr/local/src/tor-0.2.5.10. *** [all] Error code 1 Stop in /usr/local/src/tor-0.2.5.10. -------------------------------------- Has anyone has any luck building Tor against LibreSSL? -- Seth I <3 nicely trimmed email replies

2 2

OrPort self-testing sometimes fails
by Julien ROBIN 21 Nov '14

21 Nov '14

Hi everybody, Second time it happen to me so I would like to know if you have ideas about it. Sometimes after a reboot, I haven't the following message into the log : "Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor." And after a while (fortunately), I receive a warning (Tor Weather) because my server is shown as offline. So I just type /etc/init.d/tor stop and /etc/init.d/tor start, and it works fine. I would like to know how does the test works, in order to check what can fail during the test. If my server's IP (95.130.9.190) is not reachable by a part of the Internet for example, in order to open a support ticket with my ISP (do you know how I can easily check it ?). Also, since few month now, the bandwith usage seems to keeps far below what I had before (even with a good consensus weight, fresh OS install with new keys and name a month ago) so I now realize that may be there is a problem somewhere with this machine. Thank you in advance for your help and ideas ! Best Regards, Julien ROBIN ---- Please find below the logs of the "failed" start, followed by the "working" start Nov 21 11:56:53.000 [notice] Tor 0.2.5.10 (git-43a5f3d91e726291) opening log file. Nov 21 11:56:53.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. Nov 21 11:56:53.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Nov 21 11:56:53.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. Nov 21 11:56:53.000 [notice] Caching new entry debian-tor for debian-tor Nov 21 11:56:53.000 [notice] Caching new entry debian-tor for debian-tor Nov 21 11:56:53.000 [notice] Your Tor server's identity key fingerprint is 'MagnetronFR1 145AEE9359A8943189500C5451722CAA7EEEC6C3' Nov 21 11:56:53.000 [notice] Bootstrapped 0%: Starting Nov 21 11:56:57.000 [notice] We now have enough directory information to build circuits. Nov 21 11:56:57.000 [notice] Bootstrapped 80%: Connecting to the Tor network Nov 21 11:56:57.000 [notice] Bootstrapped 85%: Finishing handshake with first hop Nov 21 11:56:58.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Nov 21 11:57:00.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Nov 21 11:57:00.000 [notice] Bootstrapped 100%: Done Nov 21 13:56:58.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Nov 21 13:57:28.000 [notice] Clean shutdown finished. Exiting. Nov 21 13:57:39.000 [notice] Tor 0.2.5.10 (git-43a5f3d91e726291) opening log file. Nov 21 13:57:39.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. Nov 21 13:57:39.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Nov 21 13:57:39.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. Nov 21 13:57:39.000 [notice] Caching new entry debian-tor for debian-tor Nov 21 13:57:39.000 [notice] Caching new entry debian-tor for debian-tor Nov 21 13:57:39.000 [notice] Your Tor server's identity key fingerprint is 'MagnetronFR1 145AEE9359A8943189500C5451722CAA7EEEC6C3' Nov 21 13:57:39.000 [notice] Bootstrapped 0%: Starting Nov 21 13:57:39.000 [notice] Bootstrapped 5%: Connecting to directory server Nov 21 13:57:41.000 [notice] We now have enough directory information to build circuits. Nov 21 13:57:41.000 [notice] Bootstrapped 80%: Connecting to the Tor network Nov 21 13:57:41.000 [notice] Bootstrapped 85%: Finishing handshake with first hop Nov 21 13:57:41.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Nov 21 13:57:43.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Nov 21 13:57:44.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Nov 21 13:57:44.000 [notice] Bootstrapped 100%: Done

2 1

[Tor Weather] Node Down! - AccountingMax and ORPort 80
by Chuck Peters 21 Nov '14

21 Nov '14

I thought it might be nice to run a relay only node with ORPort 80 because it might make tor more available to some users where blocking occurs. And to limit unexpected expenses I calculated 220GB a week would be good. Now I have found out why running ORPort 80 with AccountingMax is a problem... Can I work around this issue of after hibernation the node won't bind to port 80? Or do I need to set it to something above port 1024, for example the default port 9001? Initial setup includes the following: ORPort 80 AccountingMax 220 GB AccountingStart week 7 00:00 After a few weeks running the node, day 7 of the week's AccountingMax Tor Weather reports Node Down! Date: Sat, 15 Nov 2014 15:52:45 -0000 Subject: [Tor Weather] Node Down! Nov 15 14:15:09.000 [notice] Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted Nov 15 15:37:55.000 [notice] Heartbeat: Tor's uptime is 10 days 12:00 hours, with 68 circuits open. I've sent 315.47 GB and received 315.06 GB. We are currently hibernating. ... Nov 16 00:00:00.000 [notice] Hibernation period ended. Resuming normal activity. Nov 16 00:00:00.000 [notice] Opening Socks listener on 127.0.0.1:9050 Nov 16 00:00:00.000 [notice] Opening OR listener on 0.0.0.0:80 Nov 16 00:00:00.000 [warn] Could not bind to 0.0.0.0:80: Permission denied I restart the server, after a bit of downtime. [1]. Following week on day 5 of the AccountingStart week I am approaching the limit again and decide to try a daily AccountingMax, and then perhaps I could restart the server with cron at 5:01, but that isn't going work well with random hibernation. ORPort 198.211.99.146:80 IPv4Only AccountingMax 32 GB AccountingStart day 05:00 Then Node Down again, this time it happens right after the AccountingStart resets. Date: Fri, 21 Nov 2014 07:13:07 -0000 Subject: [Tor Weather] Node Down! Nov 21 05:00:00.000 [notice] Configured hibernation. This interval began at 2014-11-21 05:00:00; the scheduled wake-up time is 2014-11-21 06:20:24; we expect to exhaust our quota for this interval around 2014-11-22 04:16:24; the next interval begins at 2014-11-22 05:00:00 (all times local) Nov 21 05:00:01.000 [notice] Commencing hibernation. We will wake up at 2014-11-21 06:20:24 local time. Nov 21 05:00:01.000 [notice] Going dormant. Blowing away remaining connections. Nov 21 06:20:24.000 [notice] Hibernation period ended. Resuming normal activity. Nov 21 06:20:24.000 [notice] Opening Socks listener on 127.0.0.1:9050 Nov 21 06:20:24.000 [notice] Opening OR listener on 198.211.99.146:80 Nov 21 06:20:24.000 [warn] Could not bind to 198.211.99.146:80: Permission denied ... after logrotate runs Nov 21 07:46:25.000 [warn] Could not bind to 198.211.99.146:80: Permission denied Nov 21 07:46:25.000 [warn] Failed to parse/validate config: Failed to bind one of the listener ports. Nov 21 07:46:25.000 [err] Reading config failed--see warnings above. For usage, try -h. Nov 21 07:46:25.000 [warn] Restart failed (config error?). Exiting. I would like to run an exit node, but the advise seems to be try a relay only node for 6 months to a year first... It seems it might be more of an issue with expenses that might prevent me from running an exit node, or multiple nodes. I'l upgrade the VPS to the 2TB transfer, but that might be after the holidays. However I suspect that it will only be a matter of days or weeks before I run into the AccountingMax limits and that may preclude changing the configuration to be an exit node. 1. Downtime starting the 15th. eth0 08:59 ^ t | rt rt | rt rt rt | rt rt rt | t rt rt rt rt | rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt rt rt -+---------------------------------------------------------------------------> | 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 00 01 02 03 04 05 06 07 08 h rx (KiB) tx (KiB) h rx (KiB) tx (KiB) h rx (KiB) tx (KiB) 09 1,380,268 1,409,649 17 1,244 2,753 01 3,117 6,815 10 1,383,154 1,407,057 18 1,100 1,720 02 161,632 164,035 11 1,143,056 1,163,393 19 706 228 03 1,564,910 1,578,327 12 1,920,541 1,953,502 20 127 201 04 1,036,805 1,054,792 13 2,719,316 2,742,037 21 675 222 05 1,630,340 1,644,128 14 854,474 869,997 22 124 150 06 3,189,069 3,215,147 15 81,036 82,419 23 732 324 07 2,952,173 2,999,409 16 52,548 52,515 00 6,367 2,718 08 2,115,794 2,150,727 ------------------------------------------------------------------------------- And some other stats that seem to follow the expected life cycle. day rx | tx | total | avg. rate ------------------------+-------------+-------------+--------------- 10/06/2014 28.32 MiB | 13.31 MiB | 41.63 MiB | 0.49 KiB/s 10/07/2014 37.10 MiB | 30.33 MiB | 67.43 MiB | 0.80 KiB/s 10/08/2014 200.13 MiB | 170.99 MiB | 371.12 MiB | 4.40 KiB/s 10/09/2014 194.58 MiB | 188.91 MiB | 383.49 MiB | 4.55 KiB/s 10/10/2014 578.48 MiB | 588.95 MiB | 1.14 GiB | 13.84 KiB/s 10/11/2014 1.09 GiB | 1.10 GiB | 2.19 GiB | 26.62 KiB/s 10/12/2014 1.34 GiB | 1.34 GiB | 2.68 GiB | 32.57 KiB/s 10/13/2014 977.57 MiB | 984.14 MiB | 1.92 GiB | 23.25 KiB/s 10/14/2014 1.68 GiB | 1.67 GiB | 3.34 GiB | 40.56 KiB/s 10/15/2014 1.35 GiB | 1.36 GiB | 2.71 GiB | 32.91 KiB/s 10/16/2014 8.49 GiB | 8.58 GiB | 17.07 GiB | 207.20 KiB/s 10/17/2014 11.88 GiB | 12.02 GiB | 23.91 GiB | 290.15 KiB/s 10/18/2014 13.33 GiB | 13.55 GiB | 26.88 GiB | 326.25 KiB/s 10/19/2014 15.95 GiB | 16.19 GiB | 32.15 GiB | 390.12 KiB/s 10/20/2014 12.34 GiB | 12.53 GiB | 24.87 GiB | 301.83 KiB/s 10/21/2014 17.41 GiB | 17.68 GiB | 35.10 GiB | 425.94 KiB/s 10/22/2014 23.84 GiB | 24.21 GiB | 48.04 GiB | 583.08 KiB/s 10/23/2014 26.52 GiB | 26.93 GiB | 53.46 GiB | 648.77 KiB/s 10/24/2014 26.19 GiB | 26.60 GiB | 52.79 GiB | 640.64 KiB/s 10/25/2014 24.77 GiB | 25.13 GiB | 49.89 GiB | 605.53 KiB/s 10/26/2014 32.19 GiB | 32.66 GiB | 64.86 GiB | 787.13 KiB/s 10/27/2014 28.44 GiB | 28.84 GiB | 57.28 GiB | 695.12 KiB/s 10/28/2014 24.39 GiB | 24.80 GiB | 49.19 GiB | 596.97 KiB/s 10/29/2014 23.66 GiB | 24.04 GiB | 47.70 GiB | 578.94 KiB/s 10/30/2014 26.16 GiB | 26.64 GiB | 52.80 GiB | 640.83 KiB/s 10/31/2014 24.48 GiB | 24.94 GiB | 49.42 GiB | 599.75 KiB/s 11/01/2014 26.62 GiB | 27.02 GiB | 53.64 GiB | 650.94 KiB/s 11/02/2014 26.65 GiB | 27.02 GiB | 53.67 GiB | 651.32 KiB/s 11/03/2014 25.09 GiB | 25.51 GiB | 50.60 GiB | 614.08 KiB/s 11/04/2014 25.06 GiB | 25.43 GiB | 50.49 GiB | 612.75 KiB/s 11/05/2014 27.74 GiB | 28.17 GiB | 55.91 GiB | 678.50 KiB/s 11/06/2014 23.62 GiB | 23.98 GiB | 47.61 GiB | 577.79 KiB/s 11/07/2014 26.63 GiB | 27.06 GiB | 53.69 GiB | 651.61 KiB/s 11/08/2014 30.29 GiB | 30.73 GiB | 61.02 GiB | 740.58 KiB/s 11/09/2014 30.93 GiB | 31.38 GiB | 62.32 GiB | 756.31 KiB/s 11/10/2014 37.56 GiB | 38.16 GiB | 75.72 GiB | 918.98 KiB/s 11/11/2014 33.97 GiB | 34.46 GiB | 68.43 GiB | 830.48 KiB/s 11/12/2014 37.92 GiB | 38.52 GiB | 76.45 GiB | 927.78 KiB/s 11/13/2014 32.15 GiB | 32.65 GiB | 64.80 GiB | 786.41 KiB/s 11/14/2014 36.32 GiB | 36.81 GiB | 73.14 GiB | 887.61 KiB/s 11/15/2014 25.40 GiB | 25.75 GiB | 51.15 GiB | 812.74 KiB/s 11/16/2014 44.23 GiB | 44.88 GiB | 89.11 GiB | 1.06 MiB/s 11/17/2014 44.96 GiB | 45.64 GiB | 90.60 GiB | 1.07 MiB/s 11/18/2014 48.38 GiB | 49.16 GiB | 97.53 GiB | 1.16 MiB/s 11/19/2014 51.38 GiB | 52.33 GiB | 103.71 GiB | 1.23 MiB/s 11/20/2014 43.68 GiB | 44.43 GiB | 88.11 GiB | 1.04 MiB/s 11/21/2014 5.52 GiB | 5.62 GiB | 11.14 GiB | 398.39 KiB/s Chuck

3 2

Re-installed Tor relay node as exit node with same name, different OS.
by Seth 19 Nov '14

19 Nov '14

I recently re-installed the operating system for a VPS that was running Parabola GNU/Linux and acting as a Tor relay. The new OS is OpenBSD 5.6 running tor-0.2.5.10. Instead of running as a relay I modified torrc so it runs a ReducedExitPolicy policy. Initially there were several problems with Tor exit node traffic being blocked by the firewall which has since been resolved. The Tor status page however still does not list this router as an exit node. http://jlve2y45zacpbz6s.onion/router_detail.php?FP=e1e1059d8c41fc48b823c6f0… Any ideas why? -- Seth I <3 nicely trimmed email replies

2 2

BSDNow, OpenBSD Journal
by Libertas 19 Nov '14

19 Nov '14

1 0

List of Relays' Available SSH Auth Methods
by Libertas 18 Nov '14

18 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, everyone. Linked below is a list of relays that were live last night along with the SSH authentication methods they support: https://gist.githubusercontent.com/plsql/27e80e6dab421f8cba6c/raw/8bb0c7aa9… If no auth methods are listed, the SSH connection to the relay failed (more on that below). I used this script to generate it: https://github.com/plsql/ssh-auth-methods The purpose of this is to alert relay operators that are still allowing password authentication. 2,051 relays offered password auth, and many more likely offer similarly insecure methods or were missed for reasons discussed below. Generally, it is far more secure to allow only public key auth. The Ubuntu help pages have a good guide on setting up key-based auth: https://help.ubuntu.com/community/SSH/OpenSSH/Keys Be sure to disable password authentication after you get key-based auth working! https://help.ubuntu.com/community/SSH/OpenSSH/Configuring#disable-password-… To test whether password auth is still supported, use my script (the README is pretty thorough) or try SSHing from a machine that doesn't have access to your private key. In the latter case, you should get the response 'Permission denied (publickey).' immediately. If you're having issues, make sure that you've restarted sshd since the last time you changed the config. Be sure to back up the node's secret key or your SSH private key, but only somewhere safe! For example, store it in a password manager database on Tarsnap or a USB. This script doesn't attempt any kind of authentication or unauthorized access, so it's about as benign as network scanning scripts come. Regardless, let me know if you have any concerns. It made successful SSH connections with 2839 / 6551 relays. Reasons for failure include: * SSH being served on a non-standard port - something other than port 22. This is a good idea, as many brute-force attackers will only bother trying port 22. The script I wrote could have used an alternate port number supplied from nmap, but this would run much slower and would potentially get my VPS blocked before it could even get the SSH information. * The server only allowing SSH connections from certain IP addresses. This is also commonly recommended, although it can be a little rigid if you don't have a VPN with a static IP (what if your server goes down while you're away from home?). * The server going down between when I downloaded the consensus and when I ran the script. * My VPS's IP address getting added to a shared blacklist that the server uses. * etc. If I gave any poor advice or got anything wrong, please let me know. Libertas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUa2ExAAoJELxHvGCsI27Np8IP/2duANtd55hs5L9IskFD2REe 9x5TR+uwZ54GhYLiFc+qiX3JnfoxfurZW7vi++D4R3E9L7nGo5weEZd0b88yJ6kx fUT9QG8gq2RFYdG+RQgYoEI9mLNObK/uc6J9qV3Y7dLOE/may6t6BDWpQTh7g5BJ 8fOnhrqjs0JdfTldc6xzrHT+m1dKBpylWus/WwGaJBReKOx6v7FoMEY53qowK0iA Vb5QS4idYb5WWF+K3Uzqk56v6sUzds/LTTlVc/R6mxjdse4AiMXO3DZsEffhI95W 8xSuw45e/Cfv/j80njsm4O1gFnrqyv/KcGwmL7vNPmtH4+i6dijTbBRroVElm1o3 LQBgCdUmQLz7njeprKnw8xdKT9X3oht4p9VZDfqWogXGiqRRdEtQCVUVhJp+ZrPA KrJBtV/IbYxyndhzC5cMAcTQUff0SOvDtzFnC4cxUbxSemtuO1NMwnIZtv3aGmG5 NEfXS3RjaUlZeZPZuymBDL1CnFqki6+eBDvka8ZOhL1/BgmDqcgT7nRWhlC5MtCG wBAfuJWB8BZl2PHg66VUN9X05TeHbVmrlyuRXaZO6SZof0Wp5vPjzJ1mKD6AyTlt Y/7liLapWgCVSYldohvbLB016iO/aHyGf3oTvZqUyG3NyD267aRQCDQ+sZZq7Cdz +eQO5eJLW/gFNXEptaJz =alRk -----END PGP SIGNATURE-----

19 30

Call for obfs4 bridges, and a brief discussion of obfs4proxy.
by Yawning Angel 18 Nov '14

18 Nov '14

Hello everyone, As people who have been following Tor Weekly News or other news sources, I have been working on a new pluggable transport in the obfs-line to better allow censored users to reach the Tor network. The result, obfs4 is what I would consider ready for general deployment[0], and as part of the process there needs to be bridges for the users. To entice people to run obfs4 bridges, I would like to talk briefly about obfs4 and obfs4proxy. I am also planning on doing a blog post about obfs4 some time after I regenerate my experimental TBB snapshots. On obfs4: obfs4 is the next up and coming pluggable transport in the obfs[2,3] line, though in terms of design, a better name would be "ScrambleSuit 2". The main difference is the switch from UniformDH to ntor-with-Elligator2 for the key exchange process, which means that clients strongly authenticate the identity of the bridge (The key exchange succeeding means that the bridge possesses a Curve25519 private key that is known only to the bridge). Additionally the ntor handshake (even with the Elligator2 transform in the picture) is considerably faster than UniformDH which should increase scalability. On obfs4proxy: obfs4proxy is the current obfs4 reference implementation, written in the Go programming language. The use of Go was primarily driven by the availability of an Elligator2 implementation at the time, though it also has other practical benefits over writing it as a component of the python obfsproxy code, for example, it is trivial to run bridges listening on ports < 1024 on modern Linux systems. obfs4proxy implements support for obfs[2,3,4], as a managed tor pluggable transport (no standalone mode currently). Note that obfs2 support is for backward compatibility purposes only and it is discouraged that new obfs2 bridges are run as the protocol is trivially broken by most adversaries. In terms of code stability, we have been running one of the Tor Browser's default obfs3 bridges on obfs4proxy for quite a while with no issues. Similar to ScrambleSuit, obfs4 bridges MUST be running tor-0.2.5.x, otherwise the bridge lines that are published will be useless[1], though people that wish to run obfs3 bridges with obfs4proxy naturally can do so with tor-0.2.4.x. Source: https://gitweb.torproject.org/pluggable-transports/obfs4.git Debian packages (Thanks Lunar!): https://packages.debian.org/sid/obfs4proxy Note: I just tagged/pushed obfs4proxy-0.0.2, but the only significant change is that it is easier to get an obfs4 bridge line to give out to people as the bridge operator. I expect packages to catch up as the wonderful packager has the time. Questions, comments, and bridges appreciated, -- Yawning Angel [0]: https://trac.torproject.org/projects/tor/ticket/12130 [1]: https://trac.torproject.org/projects/tor/ticket/13202

5 12

FYI: ISP's and blocked Authorities
by Sebastian Urbach 17 Nov '14

17 Nov '14

Hi, It seems to be the case that a few ISP's are not up to date and still using old IP's to block Authorities. That means if you are able to connect to just 1 or 2 Authorities but not to all of them your ISP could be one of those candidates. I saw this behaviour in one case just today. Connectivity with Gabelmoo and longclaw was possible but no other Authority was reachable. Gabelmoo recently changed the IP and longclaw is brand new afaik. That ISP is clearly using an old list of IPs to block Tor for their VPS systems. What makes it even worse is that this system was going to be a Non-Exit relay :-( I will ask the operator for more details and the good/bad ISP page will be updated accordingly. If you can reach some Authorities (not all) and you are not getting indexed and measured (also you can't find your system on the Atlas / Tor site), this could be the reason why. -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ----------------------------------------- Definition of TOR: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

3 4

Re: [tor-relays] Obfsproxy apparmor profile etc.
by thegreatwent＠Safe-mail.net 15 Nov '14

15 Nov '14

OK, I updated the obfsproxy apparmor profile so it works for both standalone and managed obfs3. Needed to add a line to /etc/apparmor.d/local/system_tor too. Profiles below and included in the attachment along with an init.d definition. /etc/apparmor.d/usr.bin.obfsproxy ------------------- #include <tunables/global> # vim:syntax=apparmor /usr/bin/obfsproxy { #include <abstractions/base> #include <abstractions/python> network inet stream, /dev/random r, /dev/urandom r, /etc/nsswitch.conf r, /etc/passwd r, /usr/** r, /usr/bin/obfsproxy rix, /var/log/tor/obfsproxy rw, signal (receive) set=("term") peer=system_tor, } ------------------- /etc/apparmor.d/local/system_tor ------------------- # Site-specific additions and overrides for system_tor. # For more details, please see /etc/apparmor.d/local/README. signal (send) set=("term") peer=/usr/bin/obfsproxy, -------------------

1 0