Opened 4 years ago

Closed 3 years ago

#12727 closed defect (wontfix)

Vanilla Tor Connectivity Issues In Iran -- Directory Authorities Blocked?

Reported by: cda Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version: Tor: 0.2.4.13-alpha
Severity: Keywords: iran censorship blocking
Cc: mrphs Actual Points:
Parent ID: #7141 Points:
Reviewer: Sponsor:

Description

Social media users and @mttp report that vanilla Tor no longer works.

Confirmed that Tor v0.2.2.35 out of the box fails to progress beyond:

Bootstrapped 5%: Connecting to directory server.

Same behavior confirmed on v0.2.4.23 built from source.

Fetched random bridge from bridges.tpo and applied to torrc, quickly bootstrapped through bridge and successfully confirmed access through check.tpo.

With stem-listed DAs, wrote python script to check connectivity to DAs based on a simple TCP connect(). For OR port, if successful, the cert sha1 was retrieved.

Connect Test Results for directory authorities:

Tonga 82.94.251.203 (OR: 443 , 14:C7:A1:55:82:1C:D4:81:5C:55:8F:25:E5:7F:CF:F0:3E:BF:67:30 ), (Dir: 80 , successful )
turtles 76.73.17.194 (OR: 9090 , timeout ), (Dir: 9030 , timeout )
dizum 194.109.206.212 (OR: 443 , timeout ), (Dir: 80 , timeout )
gabelmoo 212.112.245.170 (OR: 443 , timeout ), (Dir: 80 , timeout )
urras 208.83.223.34 (OR: 80 , timeout ), (Dir: 443 , timeout )
tor26 86.59.21.38 (OR: 443 , timeout ), (Dir: 80 , timeout )
moria1 128.31.0.39 (OR: 9101 , 97:4B:DD:96:D3:21:1F:52:F9:8C:0A:BB:7C:27:3B:19:7F:02:5A:1D ), (Dir: 9131 , successful )
dannenberg 193.23.244.244 (OR: 443 , timeout ), (Dir: 80 , timeout )
Faravahar 154.35.32.5 (OR: 443 , timeout ), (Dir: 80 , timeout )
maatuska 171.25.193.9 (OR: 80 , timeout ), (Dir: 443 , timeout )

TCP traceroute to Faravahar dies at the Telecommunications Company of Iran for all TCP ports (ICMP is fine).

traceroute to 154.35.32.5 (154.35.32.5), 30 hops max, 60 byte packets
 1  [hop-1, responsive]
 2  [hop-2, unresponsive]
 3  [hop-3, responsive]
 4  [hop-4, responsive]
 5  78.38.255.100 (78.38.255.100)  1.300 ms  1.127 ms  1.334 ms
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
[...]

Taken against the successful ICMP traceroute, the next hop hits 10.10.53.209 then exits Iran through PCCW Global. Based on the TCI's history in past disruptions, that this would occur at the international gateway is unsurprising and indicates that all users on unprivileged networks are likely blocked unless using a bridge.

For posterity, 10.10.53.209 only has one open port, HTTP on 80, which returns the "level 15 access" authentication message indicative that it is a Cisco router.

Child Tickets

Change History (12)

comment:1 in reply to:  description ; Changed 4 years ago by mttp

Replying to cda:

Fetched random bridge from bridges.tpo and applied to torrc, quickly bootstrapped through bridge and successfully confirmed access through check.tpo.

Regular-type bridges, right (ORPort)? Using bridges with a specific pluggable transport (obfs3 for example) wasn't necessary?

comment:2 in reply to:  1 Changed 4 years ago by arma

Replying to mttp:

Regular-type bridges, right (ORPort)? Using bridges with a specific pluggable transport (obfs3 for example) wasn't necessary?

(Jumping in for Collin)

My impression is that vanilla bridges worked great. His theory is that it is simple blocking by IP:port.

comment:3 Changed 4 years ago by cda

My impression is that vanilla bridges worked great. His theory is that it is simple blocking by IP:port.

Thanks, that is correct. As long as the bridge offers directory data to the client, it should work after. I did nothing more than visit bridges.tpo for a generic (non-PT) bridge, and was able to connect without interference.

comment:4 Changed 4 years ago by harmony

I was under the impression that Farsi help desk should be giving out obfs3 to Iranian users as a matter of course. Do you think we should go for vanilla bridges first, then obfs3 if that doesn't work, or giving out some of each kind? Or does it not really matter?

comment:5 Changed 4 years ago by cda

Do you think we should go for vanilla bridges first, then obfs3 if that doesn't work, or giving out some of each kind? Or does it not really matter?

I do not think it matters for these purposes but suspect that obfs3 may be more sustainable as an attack on vanilla bridges seems more likely (so long as the whitelisting regime in not reimposed [1]).

[1] PDF: http://smallmedia.org.uk/InfoFlowReportAPRIL.pdf

comment:6 Changed 4 years ago by mrphs

Cc: mrphs added

comment:7 Changed 4 years ago by cypherpunks

Keywords: iran censorship blocking added

comment:8 Changed 3 years ago by mrphs

Parent ID: #7141

comment:9 Changed 3 years ago by arma

For those excited to see progress on this ticket, you should consider working on #15228.

comment:10 Changed 3 years ago by dcf

Resolution: wontfix
Status: newclosed

Closing as this is pretty old and it seems users are working around it, if the directory authority block is still in place.

You can see an interesting phenomenon in relay/bridge users. Relay users go down at the same time that bridge users go up.

https://metrics.torproject.org/userstats-relay-country.html?graph=userstats-relay-country&start=2014-01-01&end=2015-01-01&country=ir&events=off
https://metrics.torproject.org/userstats-relay-country.html?graph=userstats-relay-country&start=2014-01-01&end=2015-01-01&country=ir&events=off

https://metrics.torproject.org/userstats-bridge-country.html?graph=userstats-bridge-country&start=2014-01-01&end=2015-01-01&country=ir
https://metrics.torproject.org/userstats-bridge-country.html?graph=userstats-bridge-country&start=2014-01-01&end=2015-01-01&country=ir

Note: See TracTickets for help on using tickets.