tor-relays

tor-relays@lists.torproject.org

36 participants
4815 discussions

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

12 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 12 Jan '16

12 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 09 Jan '16

09 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 09 Jan '16

09 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays