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.
On 16 Jan 2016, at 09:08, Test This emu.x86.64@gmail.com wrote:
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.
We're working on a fix for this issue, by providing tor clients with a list of fallback directory mirrors This allows clients which can't reach the directory authorities to bootstrap. (But it doesn't resolve the issue for relays, which need to be able to reach the authorities.) We're trialling fallback directory mirrors in the 0.2.8 alpha series. https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors
Another fix for this issue has clients try multiple directory authorities (or fallback directory mirrors) when bootstrapping. This makes bootstrap more reliable when only a few directory authorities are reachable. (It also doesn't help relays, because they need to be able to reach the authorities.) https://trac.torproject.org/projects/tor/ticket/4483 https://trac.torproject.org/projects/tor/ticket/4483
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
tor-relays@lists.torproject.org