- tor-relays - lists.torproject.org

Running a relay, only, in win7
by je suis 19 Jan '16

19 Jan '16

Hello all I'm sorry if I'm writing to the wrong list. Until recently and since some months back, I ran a tor relay under Linux, during daytime (only have my laptop), with 2.5/5MBps speed. Not much, it took an hour or two to really start, but it worked, I hope it helped a bit. Now I find I need to spend time in win7 more and I'd like to keep on running a relay, but I can't seem to get tor to work. Since the FAQ only says what Linux users should do and all my searches turned out to have Vidalia involved, I don't know how to make this work, so I'm asking for help: is there a place where I can read, or could you tell me what I need to do to run a relay in win7? Thank you in advance, Vlad

4 6

atlas not showing 3 days and 1 week graphs
by krishna e bera 19 Jan '16

19 Jan '16

Is atlas.torproject.org broken or changed? It seems to show only 1 month and longer graphs now.

5 6

Re: [tor-relays] Revised Opt-In Trial: Fallback Directory Mirrors
by starlight.2016q1＠binnacle.cx 18 Jan '16

18 Jan '16

I'd guess a bug in the version update script. At 19:20 1/12/2016 +0100, Aeris wrote: >> Are you *absoultely* certain that the config >> was not fiddled with at the time of this event? > >After grepping some logs, seems 13/12 was the day of a Tor >upgrade : > >2015-12-13 10:47:31 upgrade tor:amd64 0.2.7.5-1~d80.jessie+1 0.2.7.6-1~d80.jessie+1 >2015-12-13 10:48:39 configure tor:amd64 0.2.7.6-1~d80.jessie+1 > >Timing is good compare to the 10:48:46 of the consensus ! > >But I donât remember a config change after that, >perhaps only on /usr/share/tor/tor-service-defaults-torrc >or on a default config param change ? > >And perhaps the Tor reboot cause the DirPort to >be temporarily disabled (seems not human, only >2s duration) ? > >Regards, >-- >Aeris

2 4

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors
by starlight.2015q3＠binnacle.cx 18 Jan '16

18 Jan '16

Relay 'Binnacle' experienced outages due to a loose fiber-option junction in the overhead wires that has been repaired. I believe it would make the list if not for this and do not foresee further trouble. Has a static IP and another Verizon FiOS relay qualifies, a positive reflection on the network. Available if desired. Can configure IPv6 on the HE tunnel here if helpful. $ python updateFallbackDirs.py DEBUG:root:Failed to get an ipv6 address for 4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF1F2. DEBUG:root:Adding uptime 4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF1F2. DEBUG:root:4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF1F2 not a candidate: guard avg too low (0.910189) { "dir_address":"108.53.208.157:80", "or_addresses":["108.53.208.157:443"], "contact":"starlight dot YYYYqQ at binnacle dot cx", "consensus_weight":17500, "fingerprint":"4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF1F2", "recommended_version":true, "nickname":"Binnacle", "last_changed_address_or_port":"2015-06-12 18:00:00" }

3 3

Revised Opt-In Trial: Fallback Directory Mirrors
by Tim Wilson-Brown - teor 17 Jan '16

17 Jan '16

Hi all, Nick sent an email in December[0] asking relay operators to opt-in as a fallback directory mirror. This will help tor clients reach the tor network, and reduce the load on directory authorities.[1] We will keep the opt-ins and opt-outs submitted so far - no need to opt-in or opt-out again! If you run an under-utilised exit, we encourage you to opt-in as a fallback directory. We've also fixed a major bug that excluded some relays from the list. (Thanks starlight!) Here's the latest list of fallback directory candidates: https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_d… <https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_d…> This list was generated a few minutes ago from scripts/maint/updateFallbackDirs.py in my branch fallback-17887-17888-18035 on [2]. (This branch has some bug fixes compared to what's in master.) Tim [0]: https://lists.torproject.org/pipermail/tor-relays/2015-December/008361.html <https://lists.torproject.org/pipermail/tor-relays/2015-December/008361.html> [1]: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors <https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors> [2]: https://github.com/teor2345/tor.git <https://github.com/teor2345/tor.git> Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

6 13

Opt-In Trial: Fallback Directory Mirrors
by Felix 17 Jan '16

17 Jan '16

Hi I'm happy to bring in the relay Doedel22 '8FA37B93397015B2BC5A525C908485260BE9F422'. Best regards, Felix

3 2

Do less-secure pluggable transports on bridges render more-secure types useless?
by Rick Huebner 17 Jan '16

17 Jan '16

I've read that obfs4 and scramblesuit are very resistant ("immune" is so optimistic) to such things as active probes performed by the Great Firewall, which can quickly probe and detect older transports (and of course vanilla ORports), plus the older transports and ORports are subject to relatively quick detection through deep packet inspection once a user connects from there. Does it make sense to offer older more vulnerable transports along with newer more secure ones? If my bridge offers both obfs3 and obfs4, does that just mean that as soon as someone in China uses obfs3 it's detected and my IP address is blocked, making the obfs4 port unusable from there as well even though it would have avoided detection on its own? More fundamentally, does the bridge address server also publish vanilla ORports for those bridges which offer obfs4, and does a Chinese user accessing my bridge's ORport doom my entire bridge to immediate blockage from there? I can't imagine the GFW would be so kind as to only block the ORport's specific port number, I assume it blocks the entire bridge IP address, making all transports useless if any single one of them is detected. Would it be better to only offer obfs4 to avoid detection and blockage via older transports?

2 2

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors
by Joost Rijneveld 17 Jan '16

17 Jan '16

Hi all, > On 17 Dec 2015, at 15:07, Nick Mathewson wrote: > If your relay is on this list, and you expect it to be on the same IP > address(es) and port for at least 2 years, please consider opting-in > for this trial. I realise it's been a while since the last post in this thread, but I'd like to opt-in. Relay: kili DD85503F2D1F52EF9EAD621E942298F46CD2FC10 Cheers, Joost

3 3

Tor being blocked by mayor ISP in Mexico?
by Test This 17 Jan '16

17 Jan '16

Tor being blocked by mayor ISP in Mexico? I've been running an exit relay for about 2 years. Since new year's day, I noticed that my relay went down and was no longer listed in Globe or Atlas. Just like Fabian Bustillos Vega reported here: https://lists.torproject.org/pipermail/tor-relays/2016-January/008491.html a few days ago. Software version at the time: (was running without problems for almost five months) Tor: 2.6.10 openSSL: 1.0.1i libevent: 2.0.21 running on Linux At first, I thought it was a configuration error, so I double checked the TORRC file manually and with software (Vidalia and ARM). Everything was OK. I check the log file and found something very unusual, when trying to connect to the Tor network, there were several openSSL connection errors. Eventually after a while and several attempts, Tor connection was successful. Here's the error: *[warn]* 8 connections died in state connect()ing with SSL state (No SSL object) *[warn]* 1 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN *[warn]* Problem bootstrapping. Stuck at 50%: Loading relay descriptors. (Connection timed out; TIMEOUT; count 11; recommendation warn; host 7BE683E65D48141321C5ED92F075C55364AC7123 at 193.23.244.244:443) This happened for other host as well. Link to complete log <http://pastebin.com/vUXkfXNf>. *See note at bottom. I thought maybe some Tor's Directories went down or my router was dropping packets for some reason. Several hours later I restarted my router and tried to connect again. I got the same error. I went to the tor project website and read the release notes, I found that new versions were using a new *elliptic-curve* Diffie-Hellman function, so I decided to update Tor to version 2.7.6. The error appeared once again. I tried with The Tor Browser and again, it took a while to establish a connection. I had to abort and reconnect several times in order to establish a successful connection. With these results I tried some other software; *TAILS* (Linux distro), *Fire.Onion* (Android browser). Both got stuck as well while bootstrapping. TAILS with no intervention is able to connect after a long long while, just like my Relay. Fire.Onion just like the Tor Browser are unable to connect unless I abort and reconnect several times. Back to my Relay... When it finally connects: *[notice]* Bootstrapped 90%: Establishing a Tor circuit *[notice]* Tor has successfully opened a circuit. Looks like client functionality is working. *[notice]* Bootstrapped 100%: Done *[notice]* Now checking whether ORPort XXX.XXX.XXX.XXX:9001 and DirPort XXX.XXX.XXX.XXX:9030 are reachable... (this may take up to 20 minutes -- look for log messages indicating success) *[notice]* Self-testing indicates your DirPort is reachable from the outside. Excellent. *[notice]* Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. *[notice]* Performing bandwidth self-test...done. So I Waited a couple of hours and check in Atlas and Globe again. No luck. In the log I also get: *[notice]* Heartbeat: It seems like we are not in the cached consensus. The DIR and ONION ports are open as showed by the log, I also manually checked them using port scanners. I used other people's networks, the Tor Browser and TAILS to connect to my XXX.XXX.XXX.XXX:9030 port. In every case I got the DirPortFrontPage (html) served by Tor. As indicated by the log I have client connectivity and the Relay seems to be in order but in reality the Relay is dead. It is also worth mentioning that after a successful connection the openSSL errors no longer appear in the Relay's log. Maybe Tor is skipping those (previously faulty) servers. I can only guess. A similar thing happen with the Tor Browser, if I open it frequently, it connects fast (after a successful connection), but if is not used in days, when I launch it, it gets stuck while bootstrapping. Since TAILS is a “live” distro I can't reproduce this behavior. My Relay, the Tor Browser and Fire.Onion have a higher possibility to get stuck while bootstrapping at 0, 5, 20%. Once passed the 50~60% it get faster. My assumption is that my ISP is blocking or at least randomly dropping packets to and from well known Tor Authorities (IP blocking). I don't suspect DPI, as client functionality is working. Using bridges was not necessary when trying client functionality. I was able to connect (abort and retry). As reported by Fabian Bustillos as well. Other Observations: Tor Project <https://www.torproject.org/> website, TAILS <https://tails.boum.org/> website and other Tor related pages are visible without tor. Once connected the Tor Browser is able to fetch updates. Instead of ports 9001 and 9030 I also tried 443 (OR) and 80 (DIR). *For the log, I deleted the Data directory in order to reproduce all the errors, this includes; keys, logs and cached* files.

2 1

Suggestion to make Tor usage more disguised
by Raúl Martínez 16 Jan '16

16 Jan '16

Hi, I am writing this message to make a simple suggestion that could help driving more adoption to Tor by making using tor less obvious for a network administrator. This suggestion tries to address the user case of a common Tor usage, in which the user is not being attacked nor mitm, he is just using tor in his work for example. The network admin of the office is not searching actively for Tor users in his network but one day he log-in in the router panel and he sees this: - Current conexions - WORKSTATION-98 38.29.00.2 [torproxy10.teaxxcu.com] Is obvious that is using tor. The network admin was not looking for Tor usage in his network but it saw this without looking for it. Now this worker can be in serious trouble for using Tor. So my suggestion is to set-up a custom hostname an a Tor-explaining html index ONLY in TOR EXIT nodes. They are the only nodes that can get in trouble and its helpful to advertise that they are tor nodes. ENTRY GUARD nodes should not advertise neither in the hostname nor in a HTML-index-page that they are Tor nodes. This way the network admin would only see an IP and a common hostname, that is a normal behaviour for a HTTPS request. So, having said that *I encourage all Entry-Guard owners to unset his hostname and to disable the HTML-index-page*. That could help a lot of Tor users to not draw unwanted attention. Obviously a network-admin can get a list of Tor relays and check if you are connecting to one of them but most of network-admins just take a look at his router info page without further investigation. Thanks for your time. TL;DR: I encourage all Entry-Guard owners to unset his hostname and to disable the HTML-index-page.

5 5

Re: [tor-relays] [tor-dev] How many exits exit from an IP address different than their OR address? (10.7%)
by grarpamp 14 Jan '16

14 Jan '16

On Wed, Jan 13, 2016 at 10:05 PM, Virgil Griffith <i(a)virgil.gr> wrote: > In our quantifications of relay diversity, knowing the IP addresses that > traffic exits from is important. Ways to have this information correctly > reported would be very helpful. Which is exactly why free to connect back through them and make your quanta and know for yourself or for some research statisticals. But it is the apparent disappreciation for and implied calls to remove them or to publish consensusify their would be formerly stealthy feature use that is a problem from this view. Users use them to access things around censorship, there is no higher purpose of Tor.

1 0

avoid exclusion from FallBack Dir list: do not start during minute 49
by starlight.2016q1＠binnacle.cx 14 Jan '16

14 Jan '16

See comment 6 in Bug #18050: Relay submitted a descriptor with 0 DirPort due to a self-test race condition https://trac.torproject.org/projects/tor/ticket/18050

1 0

probable FallbackDir relay determination bug
by starlight.2016q1＠binnacle.cx 12 Jan '16

12 Jan '16

Dug into the situation Aeris reported where his kitten1 relay was nixed off the fallback directory list due to a single consensus where the dir-port was published as zero. Quickly found three additional very fast very stable relays where the same thing happened: BF0FB582E37F738CD33C3651125F2772705BB8E8 12-28:17 quadhead C43FA6474A9F071E9120DF63ED6EB8FDBA105234 12-25:03 ArachnideFR5 5665A3904C89E22E971305EE8C1997BCA4123C69 11-15:18 GermanCraft In each case the V2Dir flag and DirPort are removed for a single consensus interval and then restored on the next consensus. Appears that a daemon restart is the trigger. Version update not required. Several possible causes, but the one that comes to mind is the daemon could be briefly pushing a descriptor with V2Dir inactive while completing the reacahability test for that port. This deserves to be researched further and mitigated. A possible solution is to have the script tolerate a single consensus with V2Dir removed and a reset uptime. Alternately the daemon could not push a non-V2Dir descriptor during restart and wait for the reacahability determination. I don't know enough about it to be sure the problem isn't something else. At 19:20 1/12/2016 +0100, Aeris wrote: >> Are you *absolutely* certain that the config >> was not fiddled with at the time of this event? > >After grepping some logs, seems 13/12 was the day >of a Tor upgrade: > >2015-12-13 10:47:31 upgrade tor:amd64 0.2.7.5-1~d80.jessie+1 0.2.7.6-1~d80.jessie+1 >2015-12-13 10:48:39 configure tor:amd64 0.2.7.6-1~d80.jessie+1 > >Timing is good compare to the 10:48:46 of the consensus ! > >But I don't remember a config change after that, >perhaps only on /usr/share/tor/tor-service-defaults-torrc >or on a default config param change ? > >And perhaps the Tor reboot cause the DirPort to >be temporarily disabled (seems not human, only >2s duration) ? > >Regards, >-- >Aeris

1 1

Traffic on a small Middle Relay, Advertised Bandwidth 1 MB/s
by pa011 12 Jan '16

12 Jan '16

Since about 3 months i am running a small middle relay with Advertised Bandwidth of 1 MB/s. The ISP cuts the line every night as its common on most German private DSL. The relay therefore doesn't get a stable-flag :-( What is the amount of traffic i could/should possibly generate? Is a utilization between 10 and 20 percent not too small, with 15% RAM, 0-20% CPU used only? Could i do any better? Rgds Paul

1 0

Re: [tor-relays] [tor-dev] How many exits exit from an IP address different than their OR address? (10.7%)
by grarpamp 12 Jan '16

12 Jan '16

On Tue, Jan 12, 2016 at 12:44 AM, Jesse V <kernelcorn(a)riseup.net> wrote: > This is quite interesting, thanks for the report. I'm not sure why it > would be advantageous to set up a server or network this way, but I > guess they have their reasons. 1) They may or may not be aware of their routing, or the routing applied to them. 2) Having this feature in the network doesn't break anything, except for maybe check.torproject.org, and a handful of clearnet sites that attempt and often fail to redirect you to their onion, no big deal, hit the new circuit button and try again. 3) Having this feature in the network greatly enhances Tor user's ability to select an exit and get around silly Tor blocks that rely on various consensus, RBL, DNS, whatever lists. Whether it's censorship of the source or destination, it's still censorship. And getting around censorship is one key features and critical use cases of Tor. There is no specification that says exits must exit from their OR IP, or any other IP. I seriously don't know why people continue to get their panties in a bunch over this. Please stop. Nice stats though. cc tt tr because relavance

1 0

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors
by starlight.2015q3＠binnacle.cx 11 Jan '16

11 Jan '16

At 14:24 1/12/2016 +1100, you wrote: >I've reviewed this patch and it looks good. >I updated it for the latest version of the script in the tor git repository, as it was based on an old version. great, thanks! >I've also logged the more general issue with OnionOO and date ranges as #18036. ><https://trac.torproject.org/projects/tor/ticket/18036>https://trac.torproject.org/projects/tor/ticket/18036 I looked at it more closely and I think that OnionOO does not support time-ranges in the retrieved data --one seems to always get everything. Posted a follow-up to the original forum message about this shortly after the original.

1 0

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors
by starlight.2015q3＠binnacle.cx 11 Jan '16

11 Jan '16

Found a serious bug in the updateFallbackDirs.py script used to generate the fallback relay candidate list. The OnionOO retrieval used to pull flag history returns the entire history of each relay rather than the 120 days requested. This results in 145 relays left off the list as too-old history is averaged into the percentages. While this bug appears to be in either OnionOO or in the constructed request URL (not sure which), I opted to add a maximum history age to the script. The result is 558 relays instead of the original 413. (My relay Binnacle now easily makes the cut with guard flag at 97.4 percent.) In addition several data validation bugs were discovered empirically and corrected. Changes: * support maximum history age in _avg_generic_history() * create and apply MAX_AGE_DAYS=120 in calls to _avg_generic_history() * fix division-by-zero trap in _avg_generic_history() * skip missing (i.e. null/None) intervals in _avg_generic_history() * Python timedelta.total_seconds() function not available in 2.6; replace with equivalent expression * set DEBUG logging level to make relay exclusion reasons visible * move CUTOFF_GUARD test to end in order to expose more exclusion reasons Attached to this message are 1) revised script 2) script patch Posted to PasteBin (one month expire): 3) fallback_dirs.inc as-of 2016/01/11 http://pastebin.com/8cxKCEP6 4) debug output showing causes of relay exclusions http://pastebin.com/raw/3SBpgECm

2 3

How to update tor on my raspberry
by Volker Mink 10 Jan '16

10 Jan '16

Hey there. My exit is still running on tor 0.2.4.27. How can i update it to 0.2.7.6 ? Apt-get offers no package with apt-get update and upgrade. Any hints? Best, Volker

6 6

Is Tor being blocked by ISP? (Mexico)
by Fabian Bustillos Vega 08 Jan '16

08 Jan '16

Been running a node (relay non-exit) for about 5 years. Since the new year, i noticed that my node went down, and that it did not appear on the usual places (http://torstatus.blutmagie.de/router_detail.php?FP=78382b769d5d3baa41e89e5d… and https://atlas.torproject.org/#details/78382B769D5D3BAA41E89E5D9D7FF88E1A96A…) with the last seen timestamp of 2015-12-31 20:00:00. I run my node on a dedicated server under my physical control. I checked the Tor process and in the system it was running, with the logs showing: [warn] connection_edge_process_relay_cell (at origin) failed. and [notice] Heartbeat: It seems like we are not in the cached consensus. I confirmed and double checked all my settings and restarted my Tor node, but still noticed that it was not appearing as running on globe https://globe.torproject.org/#/relay/78382B769D5D3BAA41E89E5D9D7FF88E1A96A6… or atlas https://atlas.torproject.org/#details/78382B769D5D3BAA41E89E5D9D7FF88E1A96A… after almost 6 hours. I noticed on the logs i was getting "[notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 1000 buildtimes." after restarting the node. I tried to open Tor Browser on my personal use computer, and it stalls in "connecting to a relay directory" with "Connecting to a relay directory failed (no route to host - 86.59.21.38:443)". I was however able to connect with Orbot on my smartphone after several retries. That's when i tried to ping and do a trecepath to Tor directory authorities https://atlas.torproject.org/#search/flag:authority Of the ten Tor directory authorities i was not able to ping and tracepath any of them using my ISP Telefonos del Noroeste (telnor). But i was able to ping and tracepath all of the directory authorities using Riseup's Vpn servie https://black.riseup.net/ . I even tried to traceroute directly from within the ISP provided Internet Router and was still not able to get thru to any Tor directory authority or even a Tor node. traceroute to dannenberg directory authority with Telnor ISP: traceroute to 193.23.244.244 (193.23.244.244), 30 hops max, 60 byte packets 1 192.168.254.254 (192.168.254.254) 1.500 ms 1.650 ms 2.120 ms 2 dsl-servicio-l200.uninet.net.mx (200.38.193.226) 10.721 ms 10.758 ms 10.702 ms 3 * * * 4 * * * -snip- 30 * * * traceroute to dannenberg directory authority with Riseup Vpn: traceroute to 193.23.244.244 (193.23.244.244), 30 hops max, 60 byte packets 1 10.42.0.1 (10.42.0.1) 42.364 ms 42.342 ms 42.339 ms 2 wren.riseup.net (198.252.153.1) 43.103 ms 43.103 ms 43.101 ms -snip- 22 dannenberg.torauth.de (193.23.244.244) 205.293 ms 205.783 ms 204.446 ms Similar when i tracepath to a random Tor node in france (http://torstatus.blutmagie.de/router_detail.php?FP=7407277411041dc7bee802bf…) With Telnor ISP: tracepath 149.202.193.100 1?: [LOCALHOST] pmtu 1500 1: 192.168.254.254 1.500ms 1: 192.168.254.254 1.419ms 2: no reply 3: no reply 4: no reply 5: no reply 6: no reply C With Riseup Vpn: tracepath 149.202.193.100 1?: [LOCALHOST] pmtu 1500 1: 10.42.0.1 43.093ms 1: 10.42.0.1 39.373ms 2: wren.riseup.net 44.108ms 3: gi0-0-0-5.agr13.sea02.atlas.cogentco.com 42.399ms 4: multi-use.cogentco.com 44.246ms 5: be2288.ccr21.sea02.atlas.cogentco.com 44.367ms 6: level3.sea02.atlas.cogentco.com 41.783ms asymm 7 7: no reply 8: no reply 9: nwk-1-a9.nj.us 133.351ms asymm 15 10: ldn-1-a9.uk.eu 198.174ms asymm 17 11: rbx-g1-a9.fr.eu 202.478ms asymm 17 12: fra-1-a9.de.eu 206.248ms asymm 18 13: sbg-g1-a9.fr.eu 213.218ms asymm 20 14: sbg-4b-a9.fr.eu 215.017ms asymm 21 15: ns3015177.ip-149-202-193.eu 213.182ms reached Resume: pmtu 1500 hops 15 back 21 Before the new year, there used to be around 5 to 8 Tor nodes located in Mexico, right now, only one appears as online: http://torstatus.blutmagie.de/router_detail.php?FP=92dd0214bc72cb52777e2015… that i am not able to ping or traceroute to. I have a dynamic IP, so i rebooted the ISP provided router and tried with several IP's that where assigned by my ISP and all provided the same results. I plan on doing more testing and calling my ISP and asking directly about the IP's i am not able to reach and specifically if they block or plan on blocking Tor. UPDATE: Tech support chat with ISP - Jan 02 2016: http://pastebin.com/xZuWqAkX They confirmed that i can not access the IP's but don't have any info about why i am not able to access. They "escalated" the issue... Tech support chat with ISP - Jan 03 2016: http://pastebin.com/6MA2gj9e They said: Telnor connections to the rest of the world is thru the U.S. from Telnor no blocking is made to the rest of the world. I'm not seeing any Tor nodes with telnor/telmex/infinitum at http://torstatus.blutmagie.de/index.php only Axtel and Megared. I am sometimes able to connect to "longclaw" longclaw.riseup.net (199.254.238.53) but not always. Sometimes i get "Connecting to a relay directory failed (no route to host - directory_ip:port)" when using the Tor Browser, but if i try several times i am able to use the Tor browser. I would really like to keep running my Tor node, and i am willing to change ISP's, but i am still hoping that it's something on my end, but i am not seeing any more relays with Telmex/Telnor/Infinitum as ISP. Is there anyway to confirm that it's my ISP? any other reports from Mexico about similar issues?. In the meantime, i already donated $100 while my Tor node is down. (no t-shirt yet though :( ) Tor logs here: http://pastebin.com/4XQaQyLd torrc contents: ContactInfo fabian dot bustillos at riseup dot net ControlPort 9051 DirPort 9030 ORPort 9001 ExitPolicy reject *:* HashedControlPassword ------------------------------------------------ Nickname fbnaiaTorRelay SocksListenAddress 127.0.0.1 DisableDebuggerAttachment 0

1 0

Why is Tor trying to check the wrong ORPort/DirPort addresses?
by David Tomic 08 Jan '16

08 Jan '16

Hello everyone. Long story short I have just begun experimenting with running multiple Tor instances on a couple of my servers, namely to see if it actually makes an appreciable difference to my overall throughput. I have multiple public IPs on my servers, and I would like each Tor instance to use its own dedicated address so I have configured the appropriate ip:port addresses in my second torrc file. When I start up the second instance, everything gets bound to the correct ip:port combinations (as specified in my torrc file), and I have no problems getting Tor to bootstrap and successfully open a circuit. The problem appears when Tor tries to verify that my ORPort/DirPort are reachable, because for some reason it's trying to check the wrong IP address? EG - Here are the relevant ports from my torrc file: SocksPort 9053 ControlPort 9063 Log notice file /var/log/tor/notices3.log RunAsDaemon 1 DataDirectory /var/lib/tor/3 ORPort 50.7.178.99:445 DirPort 50.7.178.99:83 When I start Tor, everything matches the above: Jan 08 11:56:23.178 [notice] Opening Socks listener on 127.0.0.1:9053 Jan 08 11:56:23.179 [notice] Opening Control listener on 127.0.0.1:9063 Jan 08 11:56:23.179 [notice] Opening OR listener on 50.7.178.99:445 Jan 08 11:56:23.179 [notice] Opening Directory listener on 50.7.178.99:83 Tor successfully bootstraps and establishes a circuit: Jan 08 11:57:13.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Jan 08 11:57:13.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Jan 08 11:57:13.000 [notice] Bootstrapped 100%: Done BUT THEN ... Jan 08 11:57:13.000 [notice] Now checking whether ORPort 50.7.178.102:444 and DirPort 50.7.178.102:83 are reachable... (this may take up to 20 minutes -- look for log messages indicating success) Notice that it's still checking the correct port from the torrc file, but not the correct ip address. I've tried different IP:port combinations, and each time it's the same result. Right port, wrong IP. I've tried now on two different servers, and had exactly the same results each time. Machines are running Debian 8.0 with Tor 0.2.7.6. I have tried installing from the Debian repo, as well as building from the latest source. No difference. What's causing this to go wrong? Is there something incredibly simple which I'm simply just not doing properly, or is there possibly more going on here than first meets the eye?

5 10

Debugging my small relay
by Markus Hitter 08 Jan '16

08 Jan '16

Hello all, for somewhat over a year now I run a Tor relay on my router. The router in turn is running OpenWRT. It's this one: https://globe.torproject.org/#/relay/A52C51551F3BD6A68E778720E02B53303F014E… https://atlas.torproject.org/#details/A52C51551F3BD6A68E778720E02B53303F014… Not much, but let it be one of my small shares for improving humanity :-) A few days ago I upgraded OpenWRT from 14.07 to 15.05, the latest release. Reinstalled the package 'tor', kept the old config file and the server started apparently smoothly. Previous Tor version was 0.2.4.22, now it's 0.2.5.12. I'm aware that these aren't exactly the latest, but that's what OpenWRT's package manager offers. As you can see in the link above, the relay is no longer recognized as 'running'. They don't recognize the new Tor version, don't recognize the restart. To what I know, /var/log/tor/notices.log looks fine, a few excerpts: Jan 02 14:34:36.000 [notice] Tor 0.2.5.12 (git-99d0579ff5e0349f) opening new log file. [... clock synchrionisation works :-) ...] Jan 04 17:35:42.000 [warn] Your system clock just jumped 183652 seconds forward; assuming established circuits no longer work. [...] Jan 04 17:38:09.000 [notice] Now checking whether ORPort x.x.x.x:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) Jan 04 17:38:15.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. [...] Jan 06 11:35:42.000 [notice] Heartbeat: Tor's uptime is 1 day 18:00 hours, with 0 circuits open. I've sent 68.73 MB and received 85.15 MB. Jan 06 11:35:42.000 [notice] Average packaged cell fullness: 76.757% Jan 06 11:35:42.000 [notice] TLS write overhead: 9% Jan 06 11:35:42.000 [notice] Circuit handshake stats since last time: 9/9 TAP, 0/0 NTor. How could I find out about what's going wrong? Thanks, Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/

4 7

The Onion Box: A web based status monitor for Tor relays
by theonionbox＠gmx.com 05 Jan '16

05 Jan '16

7 11

Running an exit? Please secure your DNS with DNSCrypt+Unbound
by Jesse V 05 Jan '16

05 Jan '16

Hey everyone, This is an advisory for anyone running an exit node, but it also applies to any Linux setup where you don't trust your DNS server. TL;DR: this is a guide for switching unsecured DNS to DNSCrypt + Unbound, which prevents a network host from monitoring DNS lookups, thus increasing privacy for everyone using Tor. A few weeks ago I set up some exits and I recently discovered that the host was using 8.8.8.8, Google's DNS, as a resolutions service. As in, they had "nameserver 8.8.8.8" in /etc/resolv.conf. Convenient for them, but it meant that every request was sent to Google for resolution. This is bad because Google can then track DNS lookups and so can anyone watching unencrypted DNS as it travels across the country. In fact, DNS is specifically mentioned in the "Tor Sucks" NSA slides. Compounding this, most Linux boxes don't use a DNS cache, so literally every lookup is sent to Google, so this didn't exactly inspire confidence. After talking with cacahuatl, ncl, and pskosinski on IRC, I switched to DNSCrypt, a FOSS protocol that encrypts DNS lookups across the wire. I also set up the Unbound DNS cache, thus accelerating queries while also preventing the DNSCrypt server from observing every lookup. Then I redirect /etc/resolv.conf to use Unbound, which itself used DNSCrypt. This protected Google or my host from watching DNS lookups. Here's how I did it: 1) I installed "unbound". I have confirmed that this package is available in the Ubuntu and Fedora repositories, so most distributions probably have it. 2) I installed "dnscrypt-proxy". I installed the libsodium-dev dependency then used https://download.dnscrypt.org/dnscrypt-proxy/ to compile and install dnscrypt-proxy from source. https://github.com/jedisct1/dnscrypt-proxy#installation may be helpful here. 3) I modified Unbound's configuration per the instructions in https://www.dnscrypt.org/#dnscrypt-proxy. For the sake of convenience, you can find my configuration here: https://gist.github.com/Jesse-V/675b7ec87eca864887e6 I then reloaded Unbound to apply the updated configuration. 4) I reviewed https://github.com/jedisct1/dnscrypt-proxy/blob/master/dnscrypt-resolvers.c… to find a provider geographically close to me. I recorded the resolver's address, provider name, and provider public key for use in the next step. 5) I ran "/usr/local/sbin/dnscrypt-proxy --resolver-address=<address> --provider-key=<publicKey> --provider-name=<name> --ephemeral-keys --local-address=127.0.53.1" in a terminal, where <address>, <publicKey>, and <name> were substituted for the information I found in step 4. 6) I ran "host torproject.org 127.0.53.1" to confirm that dnscrypt-proxy was working. 7) I ran "host torproject.org 127.0.53.53" to confirm that Unbound + dnscrypt-proxy was working. 8) I then ran the command from step 5 with the --daemonize flag so that the proxy ran in the background. 9) I added the command from step 8 to crontab, with the @reboot macro. 10) I modified /etc/resolv.conf to "nameserver 127.0.53.53". At this point "host torproject.org" should work out of the box using DNSCrypt + Unbound and nobody but you and the DNSCrypt resolver can see your query. Be sure to review https://gist.github.com/Jesse-V/675b7ec87eca864887e6 to avoid any SERVFAIL headaches. Enjoy! -- Jesse V.

9 15

Re: [tor-relays] tor hidden services & SSL EV certificate
by Manager Bahia del Sol LLC 01 Jan '16

01 Jan '16

3 2

Re: [tor-relays] Problem starting tor after upgrading to ubuntu
by Manager Bahia del Sol LLC 01 Jan '16

01 Jan '16

2 1

What are the exact requirements for HSDir flag?
by Dimitar Milkov 01 Jan '16

01 Jan '16

Hello, and Happy New Year! I have a question regarding the HSDir flag. According to dir-spec.txt : "A router is a v2 hidden service directory if it stores and serves v2 hidden service descriptors, has the Stable and Fast flag, and the authority believes that it's been up for at least 96 hours (or the current value of MinUptimeHidServDirectoryV2)." However, if you browse the consensuses, you will find a lot of relays that meet the requirements above, but doesn't have HSDir. You will also notice that almost every relay with HSDir is also a conventional v2 directory mirror (e.g. with active DirPort). Is there any non-documented requirement, like minimum bandwidth or something?

3 2

problem with new and old exit relays
by Larry Brandt 01 Jan '16

01 Jan '16

Recently I have been receiving warnings on notices.log shown below. Today I started a new exit relay and immediately received a similar message. Is this familiar to anyone? What's my problem? Dec 31 03:26:35.000 [warn] Malformed IP "???" in address pattern; rejecting. Dec 31 03:26:35.000 [warn] Couldn't parse line "[???]:*". Dropping Dec 31 03:26:35.000 [warn] Malformed policy 'reject [???]:*'. Discarding entire policy list. Dec 31 03:26:35.000 [warn] append_exit_policy_string(): Bug: Unable to parse internally generated policy reject [???]:* (on Tor 0.2.7.6 ) L Brandt

2 1

Problem starting tor after upgrading to ubuntu 15.10 / tor 0.2.7.6
by James Moore 31 Dec '15

31 Dec '15

Hello all, I've been running two exits for quote some time now and today I decided to update my OS and tor version but it didn't go too well. I was updating from ubuntu 15.04 / 0.2.6.10 to 15.10 / 0.2.7.6. I'm using the apt feed from deb http://deb.torproject.org/torproject.org wily main It appears that something about the AppArmor configuration is incorrect but I don't know enough about systemd/apparmor to properly diagnose it. Here are some log snippets: http://pastebin.com/8jzEiz3T It seems to come down to this tor(a)default.service: Failed at step EXEC spawning /usr/bin/tor: Operation not permitted I discovered that commenting out the Hardening section of /lib/systemd/system/tor(a)default.service get's it working again but I'd prefer not to run out-of-band configuration files. Can anyone shed light on this problem? I'm happy to provide more info. James

1 0

tor hidden services & SSL EV certificate
by Benoit Chesneau 31 Dec '15

31 Dec '15

I was at the talk this afternoon at the 32c3 and <i am wondering where can get a certificate for a .onion. Any service to suggest? Also where I should see to configure it correctly? - benoit

9 14

Tor Relay Meetup at 32c3 moved to 18:00
by Moritz Bartl 31 Dec '15

31 Dec '15

Sorry, due to some scheduling conflicts the meetup had to be moved to day 2 18:00. https://events.ccc.de/congress/2015/wiki/Session:Tor_Relay_Operators_Meetup Starts at 2015/12/28 18:00 Ends at 2015/12/28 20:00 Location Hall 13 See you! -- Moritz Bartl https://www.torservers.net/

2 1

'bug' bounty for weaknesses in Tor announced
by I 31 Dec '15

31 Dec '15

2 1

Delete
by Terry Mitchell 30 Dec '15

30 Dec '15

Please delete me from this list!! I probably should never have joined. Many thanks T.N.Mitchell -- T.N.Mitchell Binixica 195 07712 Mahon Menorca Spain Tel. 0034 971 153312 Mobile 0034 971153312

4 3

Sustained large spike in outbound traffic - what might be going on?
by David Tomic 29 Dec '15

29 Dec '15

Hello everyone, I noticed something a little bit "odd" on one of my exit relays recently, and I just wanted to ask whether anybody might be able to account for what was actually happening, and whether it's likely to warrant any further investigation? TLDR; I noticed a fairly significant spike - in excess of 30MB/s (yes, megabytes) - of outbound traffic compared to inbound. http://s2.postimg.org/cvfzqvrsp/graph.png It persisted steadily for just over an hour, until I noticed what was going on and restarted Tor (not the whole server, only Tor), at which point my traffic appeared to return to normal again. I have this relay running a a dedicated machine, with multiple physical NICs, and the ONLY thing which should be touching this NIC is my Tor traffic. Thoughts?

4 6

firefox display issue at https://globe.torproject.org
by Toralf Förster 21 Dec '15

21 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 This is the second time in a row that I suddenly can't see any longer anything on that side using my current ff profile. With an emptied/new profile it works well. B/c it happens now again I do wonder about the culprit. - -- Toralf, pgp: C4EACDDE 0076E94E -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlZ4Zy8ACgkQxOrN3gB26U418AD/ZXdK/zMvVpJZuAnGeUOlbiKh fk6JTrg/Kfdlnzd3N1EBAI7YERw1W6dG9x5uWR/RQO5Kg4ZhbV8+KvUL4txGnAnE =2DqN -----END PGP SIGNATURE-----

1 0

Very unbalanced inbound/outbound connections
by Jannis Wiese 21 Dec '15

21 Dec '15

Hi operators, for a couple of days, I see a little bit more than twice as much inbound than outbound connections on my (non-exit, non-guard) relay [0]. I have no real concern about this but I want to explain it to myself somehow. As my relay has the HSDir flag, I started looking at the statistics: The graph for relays with HSDir flags went down by approx. 500 relays in the past days [1], but that’s pretty much traceable to a lot of relays updating from Tor 0.2.6.x to 0.2.7.x (there’s a similar behaviour around Nov 23rd [2] where the updates started as well as around June 08th [3] where updates from 0.2.5.x to 0.2.6.x started). On the other hand, the number of HSDir flags was fluctuating quite a lot looking at the year up to now [4] which never had this effect on my relay. After all, looking at the graphs in atlas (as well in arm) shows no significant (= something like twice as much) difference between the inbound and outbound traffic - so I’m scratching my head now. Another open question would be if HSDir connections are considered as in- or outbound. Up to now, I held the HSDir flag responsible for the slightly higher outbound traffic… So, again: Still no real concern from my side (as my relay is running fine - if it would be an attack, I would be able to feel that, right?), but I would like to understand what’s going on. :-) Maybe one of you here has an idea about this or experienced something similar. To all of you an early “happy holidays”! Cheers, Jannis [0] https://atlas.torproject.org/#details/8827944C4BDCBDAC9079803F47823403C11A9… [1] https://metrics.torproject.org/relayflags.html?graph=relayflags&start=2015-… [2] https://metrics.torproject.org/relayflags.html?graph=relayflags&start=2015-… [3] https://metrics.torproject.org/relayflags.html?graph=relayflags&start=2015-… [4] https://metrics.torproject.org/relayflags.html?graph=relayflags&start=2015-…

2 2

Allow user to provide feedback?
by Eric Hocking 20 Dec '15

20 Dec '15

Would it be possible for there to be a way for users to provide feedback on the current tor relay/server they are using? Ex: users submit feedback such as let's say "relay is slow" when another user uses the proxy, they could see the user provided feedback of the relay

2 1

IPv6 Only Exit Node
by Hans Wurscht 20 Dec '15

20 Dec '15

Hi I would like to operate an IPv6 only exit node. I.e. it's fine if tor relays through IPv4, but I want exiting traffic only through IPv6 (because I don't want my (only) IPv4 to be blocked, abused and such). The way I thought this would work is with the ExitPolicy set as below. But atlas says my IPv6 Exit Policy Summary would be "ExitPolicy reject *:*". Now I'm wondering if my ExitPolicy is wrong defined or if that's a bug of some kind. I'm running Tor v0.2.7.5 (git-6184c873e90d93b2) on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1k and Zlib 1.2.8. # No IPv4 exit, no exit to my own subnet, no exit to private network, no exit to link local ExitPolicy reject6 [2A02:168:4A06::]/42:* # Block my subnet ExitPolicy reject6 [FC00::]/7:* # Block private IPv6 ExitPolicy reject6 [FE80::]/10:* # Block link-local IPv6 ExitPolicy reject6 [2002::]/16:* # Block 6to4 addresses ExitPolicy reject6 *:25 # SMTP ExitPolicy reject6 *:119 # NNTP ExitPolicy reject6 *:135-139 # NetBIOS ExitPolicy reject6 *:445 # Microsoft AD ExitPolicy reject6 *:563 # NNTP over TLS ExitPolicy reject6 *:1214 # Kazaa ExitPolicy reject6 *:4661-4666 # ? ExitPolicy reject6 *:6346-6429 # Gnutella ExitPolicy reject6 *:6699 # WinMX ExitPolicy reject6 *:6881-6999 # BitTorrent ExitPolicy accept6 *:* # All else ExitPolicy reject private:* # Block private IPv4 ExitPolicy reject *:* # Block all IPv4 ## If set, and we are an exit node, allow client to use us for IPv6 traffic IPv6Exit 1 -- tor.x2a.ch | https://atlas.torproject.org/#details/6FAAD7CC7EBB008AEF2E5AE1BB9082CD8BD60…

4 4

expected IPv6 traffic for an exit relay
by Toralf Förster 20 Dec '15

20 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I opened my exit for IPv6 after Moritz encouraged us to do so here at this list. I do observe a traffic of 1-2 GB. for IPv6, IPv4 is always abound 300 GB/day. The exit is configure for 8 MB/sec throughgput (==20 TB/month). I do wonder, what are expected values for IPv6. Furthermore between 11th of August and 25th of September I observed a traffic of about 30-40 GB per day for IPv6 - but why only in this time frame ? - -- Toralf, pgp: C4EACDDE 0076E94E -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlZsQtUACgkQxOrN3gB26U6q3QD/X8RceaLv8uKKcUtcO1CbugCK f2nu+JG8xBVJe+kBFCYA/jSddQ7auahsc5YSmuqgJY1fzWu43xN5kWvGG89tyzxe =/91J -----END PGP SIGNATURE-----

2 3

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors
by Raul Fournier 18 Dec '15

18 Dec '15

Feel free to opt-in my relay wagner 5525D0429BFE5DC4F1B0E9DE47A4CFA169661E33

1 0

I relay subscription
by David Smith 17 Dec '15

17 Dec '15

1 0

Re: [tor-relays] Webiron at it again...
by Juuso Lapinlampi 17 Dec '15

17 Dec '15

Bruteforce attacks generate a lot of traffic, so Webiron gets an excuse to blame the Tor network as a major source of abuse versus "regular" traffic. > "Tor: Please note as the abuse from Tor has gotten out of hand, we do > not give free passes to abuse coming from Tor exits. See the leader > board linked below for more details on the issue." We received this too. Quite oddly though, after sending them 6 or 7 email acknowledgements that our Tor exit IP-address is a Tor exit (duh), they have stopped sending us abuse complaints. Maybe we got a free pass after all, although I didn't request one. And yeah, Webiron's not to be taken very seriously.[1] I've lost their credibility a long time ago when they exclaimed that Tor exit operators would be held legally liable for the routed traffic - of course not. It's called fear mongering. -Wub [1]: https://lists.torproject.org/pipermail/tor-relays/2015-December/008259.html

1 0

ornetradar notifications from 2015-12-15
by nusenu 16 Dec '15

16 Dec '15

say hi to a bunch of new AWS servers http://article.gmane.org/gmane.network.onion-routing.ornetradar/738 subgroups: nickprefix: torpr http://article.gmane.org/gmane.network.onion-routing.ornetradar/736 Nickprefix: Willy http://article.gmane.org/gmane.network.onion-routing.ornetradar/739

1 0

Unused Tor exit nodes capacity
by Dirk Eschbach 16 Dec '15

16 Dec '15

Hello all, we are administrating 2 Tor Exits for privacyfoundation.ch [1]. In the last month we realized that the traffic which is going through our servers / throughput is by far less than the machines and the providers network can handle. We were internally and recently with Moritz from torservers.net looking at this problem but could not find a way to improve throughput. Even on the same machine the throughput between servers varies a lot with out any visible reason. I hope you can help. Our setup is two servers with a maximum of 4 tor processes (exit) each. Looking at CPU, Disk, RAM and so on the machines are not busy at all. Konsole output top - 09:57:49 up 16 days, 11:57, 1 user, load average: 1.14, 0.91, 0.81 Tasks:244 total, 3 running,241 sleeping, 0 stopped, 0 zombie %Cpu0 :12.5 us, 3.4 sy, 0.0 ni,79.7 id, 0.0 wa, 0.0 hi, 4.4 si, 0.0 st %Cpu1 :15.9 us, 5.4 sy, 0.0 ni,74.3 id, 0.3 wa, 0.0 hi, 4.1 si, 0.0 st %Cpu2 :14.3 us, 2.7 sy, 0.0 ni,77.0 id, 0.0 wa, 0.0 hi, 6.0 si, 0.0 st %Cpu3 : 9.5 us, 3.4 sy, 0.0 ni,80.3 id, 0.0 wa, 0.0 hi, 6.8 si, 0.0 st KiB Mem: 3877624 total, 2739880 used, 1137744 free, 1288 buffers KiB Swap: 4026364 total, 364264 used, 3662100 free. 10752 cached Mem Looking at the network connection it is without any problem possible to start big downloads without reducing TOR throughput. The servers are connected with 1 Gbit/s each. The big question now is: Why do the machines do not have more throughput ? Is the reason for this the way the distribution through the Tor network works. Moritz hinted it might have to do with the way the tor "bandwidth scanners" measure the ability of a server to handle traffic. Can you explain me / point me to documentation where this process is described and how this can be optimized. What are the criteria for tor exit node server traffic distribution ? How do the clients choose the exit ? I would be very happy if you could provide some answers / documentation which will set me on the right track. Thanks very much for you help. Dirk [1] https://globe.torproject.org/#/search/query=digiges

5 8

Webiron at it again...
by Schokomilch NOC 15 Dec '15

15 Dec '15

Monday we received their usual spam about our exit-node sending spam, and of course instead of implementing the TorDNSEL on their sites, they rather want us to block a whole /24 range. Anyhow, one line caught our eyes: "Tor: Please note as the abuse from Tor has gotten out of hand, we do not give free passes to abuse coming from Tor exits. See the leader board linked below for more details on the issue." They also include a link to some fancy unresolved abuse ranking[1]. From that ranking we can see that they currently have 116 unresolved Tor abuse cases and at least 500 unresolved non-Tor cases. Assuming that 616 cases are enough we can try to calculate with 99% certainty, the true interval of the difference in Tor and non-Tor abuse. We will use 500/616 = 0.812 as an estimate for all non-Tor abuse and we will use 116/616 = 0.188 as an estimate for all Tor abuse. One can easily calculate that there is a difference of 62.3% between the 81.2% non-Tor and 18.8% Tor abuse cases. However this percentage (62.3%) is just one impression of a sample. Imagine we would sample 100 hosters just like webiron and then see what their difference is. And we want to be 99% sure that our measured value is within the interval. The formula can be found here[2]. Then we would receive an interval from 0.51 to 0.73. What this boils down to: If we were to check 100 companies that send abuse reports like Webiron, in 99 cases we would find a difference between Tor and non-Tor abuse to range between 51% and 73%: Two concrete examples: Tor abuse could be as high as 24.5% (lower end of the interval -> 0.51 = 75.5 non-Tor - 24.5 Tor) or as low as 13.5% (higher end of the interval -> 0.73 = 0.865 Non-Tor - 0.135 Tor) I think that having a tiny bit less than 1/4 of all abuse reports originating from Tor is a pretty great value and not "out of hand" at all. P.S.: We are pretty sure that this calculation is correct, but don't take our word for it. Also on a funny note: Their mx server blocks our mx server, so we can't even reply to their email, even though the Tor-exit runs on a different IP than the mx. [1] https://www.webiron.com/abuse_web_leaderboard/ [2] http://www.kean.edu/~fosborne/bstat/06d2pop.html?ModPagespeed=noscript

3 2

Handling abuse request about stopforumspam.com
by Eran Sandler 15 Dec '15

15 Dec '15

Hi guys, One of my tor server seems to be getting a lot of abuse reports from the ISP from stopforumspam.com. http://www.stopforumspam.com/ipcheck/212.47.246.21 Any idea how to reduce those to a minimum in a reasonable way? Thanks, Eran

2 1

uptime "algorithm"
by Dr. Who 15 Dec '15

15 Dec '15

As far as understand it is the flag HSdir given to nodes with a fast enough connection and a long enough uptime. If I keep my tor relay version always up to the current stable version I sometimes do have to restart the process. So I get a drop in my uptime and loose the HSdir flag for several days. Other nodes who don't care about versions keep the flag, despite the fact they might use older/inefficient/insecure/buggy versions. Wouldn't it be better to monitor the reason for a drop in uptime? In case at the same time a restart occurs the version increases it might be given the HSdir flag again? someone understands what I mean?

6 5

Tor Relay Operators Meetup at 32c3: 28.12. 16:45
by Moritz Bartl 14 Dec '15

14 Dec '15

As usual: Let's all gather at 32c3 to discuss Tor relay operation! Monday, 28.12.2015 16:45-18:45 Hall 13 https://events.ccc.de/congress/2015/wiki/Session:Tor_Relay_Operators_Meetup See you there! -- Moritz Bartl https://www.torservers.net/

4 3

Relay isn't getting HSDir flags
by Lucas Werkmeister 13 Dec '15

13 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all! For some reason, my relay[1] isn't getting the HSDir and V2Dir flags. This is the full config, sans comments (sed '/^#\|^$/d' /etc/tor/torrc): SocksPort 0 DataDirectory /var/lib/tor ORPort 9001 Address 78.46.139.153 Nickname BotIfMuvasfo AccountingMax 7900 GB AccountingStart month 15 00:00 ContactInfo Lucas Werkmeister "6B89 5B8B 11A4 75B1 EC93 1698 FC46 2872 72AE 323F" <mail(a)lucaswerkmeister.de> DirPort 9030 # what port to advertise for directory connections ExitPolicy reject *:* # no exits allowed I reloaded the config several times since I uncommented the DirPort line, and even restarted the relay earlier today just in case enabling DirPort wasn't supported without restart. No luck - both Globe[1] and Atlas[2] don't show the HSDir or V2Dir flags. A few months ago, I had the relay running on a different server. I had enabled the DirPort there for a while, but eventually was forced to disable it since the server couldn't handle the load. But back then, the relay got the flags without any problem. Since I moved to a new server (copying over the torrc and data directories), this doesn't seem to be working anymore. (I am now on Debian 8, tor version 0.2.5.12; the old server was on Debian 7, tor version 0.2.4.27.) Any ideas on what the problem here could be? Thanks a lot, Lucas [1]: https://globe.torproject.org/#/relay/C527AD7D47E9DEC163537A444F4F790433CD67… [2]: https://atlas.torproject.org/#details/C527AD7D47E9DEC163537A444F4F790433CD6… -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWbfIFAAoJEPxGKHJyrjI/B3AP/18uMBavSAQeHyYDr5D89bBQ JlTmDwWdolNc7SwNeaUTB8w+KYEatyVXJh7uAF4jrjKIS9eplMMU+1rcLS6C2tO4 4hvu9cYGwXepkuh742ikPIXivj7X08BqP+c38GYyXIC/mxdUJ44AZwGa3z4guWEl 6Qb9FtdxJ2NBMdtHjvmyFTUN2qYK0k6qYzoHygCyrf/OyoHjynkMRPKwaoHEgZhG yBIcf8AlOnKUf5+cVwkUZeurZ0l0KPl0hawUNDELciOMkGchMDyb6ui6u7LbCDVL gRiBToU6RJIiPo6vKw7UbAZeNeodNeXalmLMTL7vuKzhJjYgDae1bTJEQvMWdz6i nNxssOLHhBkTwdJosj1Kaw4a+opcqA8bPJY0KeAaZUnvAGro/lOwb0Tc7oDkbg2b Xb5IuQfWpZzpOuGldfisdqXRL1rySsnCaGSsFT9ulrkXaz42UDQE8pyxy8ErqL4j byhGiQF0F04sWldQPy3AjfZEImtBROx9PetESMLLyD6UYWffEGr6JLtIoolPEA0x OjMOGuyq91gJEZ2xIdlN+kJaylmnu/8kGKD6vAJwBxX8wVHWIyD5KbQOyL2RjCT8 gtiSFdIj8mZmvKUR5svWrgxfGoVGc5a76CUyLF+7Jd+d3DPPOlGXX+dJ/WErjgjH JbmjWbI1OIBai6gKvlSE =BmwK -----END PGP SIGNATURE-----

3 3

Webtropia threatening with penalty of 5.100€
by spriver 13 Dec '15

13 Dec '15

Hi, I am (or was) running a Tor Exit Node with about 200-250bmit/s on a VPS at Webtropia for several months with the common reduced exit policy (https://globe.torproject.org/#/relay/D218DF2C542CD1FB57FCF36DB6672A0DE6A8CB…) They never had a problem with the fact of running an exit, from time to time I got an abuse mail to which I responded with the "usual thing" (that I'm running an exit and the connections are not initiated by me. If some party wishes not to be contacted I would restrict acces [exit policy]). On Monday morning my server got shut down. I contacted them by asking, why the server was shut down, they responded that some spam was sent (abuse mailing from courbis.fr, axmo12.de claimed a brute force on SSH and the usual stuff from Webiron) and thus my server was blocked by them. They now claim that they are entitled to contractual penalty of 5.100,- € to be charged because I violate their Terms of Use. Their Terms do not forbid Tor itself, but spamming and other illegal things such as port scanning and DoS-attacks (https://www.webtropia.com/de/unternehmen/agb.html) They also told me that they cannot monitor if the traffic is really Tor traffic and that I should configure my server to prevent such abuse. How should I proceed there? Cheers!

3 3

authority signatures consensus-health
by tor-server-creator＠use.startmail.com 10 Dec '15

10 Dec '15

hi, wondering what happened to consensus lately? weight-drops, list says was missing authority signatures ? thanks

3 2