- tor-relays - lists.torproject.org

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 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