Keep track of and deal with censorship by exit node ISPs

added Backlog label

figure out means how to scan for this kind of censorship

There might even be projects out there that do this kind of scanning and we could use their results to confirm findings for our exit nodes.

Another thing that would be interesting to think about: could we design something to route around this kind of censorship in an automated fashion while not compromising any of Tor's anonymity/safety guarantees?

Like it was said above: from a user's point of view there is no difference in websites blocking Tor or ISPs censoring requests: they just want to get that content. And while there might be reasons to pause with respect to websites it seems ISPs censoring requests falls into the same category as ISPs censoring access to Tor: we should think about ways routing around those.

So, some circuit-building which takes censorship into account seems worth to explore I guess. :) (famous last words, I know)

Here is another relay I stumbled upon: C1482971FE5B8F82A342BEA9CDA61F644474F0A3 which is located at AS29049 supposedly being in Azerbaijan. I can't reach our own website while using that exit, yet other websites I checked (e.g. twitter.com) are fine.

We recently saw blender.io getting censored, likely by AS12389 as we saw issues when trying to reach that website via A6BBD12D033949DC97CBA67178DC48D142A2E630 which was running on that AS at that time.

mentioned in issue #153 (closed)

#153 (closed) has some good examples of some Russian ASes blocking torproject.org and protonmail.com temporarily at least.

#153 (closed) has some good examples of some Russian ASes blocking torproject.org and protonmail.com temporarily at least.

I've been thinking a bit about this. Depending on how the censorship is implemented we might actually be able to do something. Taking the two Aramis relays in #153 (closed) blocking protonmail.com it seems requesting https://185.70.42.12 is fine (module the TLS cert warning) and we can reach Protonmail that way. Thus, I assume the censoring is implemented via the ISPs DNS resolver. One way to work around such a censor might be to ask exit operators to not use the ISPs resolver. I'll try that out with torix's two relays.

Current Russian exits messing with http://www.torproject.org/:

www-torproject-org.txt:FP BF5659C316C5BA0C047D877A8265B8A3764A280F: HTTP/1.1 302 Found
www-torproject-org.txt:FP AB32B2EA350C10888144A7ECCA7FFACA844C2052: HTTP/1.1 302 Moved Temporarily
www-torproject-org.txt:FP DEAA89B5B8D9CEAD5CE0F9281D482A4EACC30592: HTTP/1.1 302 Moved Temporarily

for http://www.torproject.org from 0CEC3D2EBB875147B045126AAA8F6DE356DCB329:

 HTTP/1.1 302 Moved Temporarily
 Cache-Control: no-cache,no-store,max-age=1
 Pragma: no-cache
 Expires: Thu, 01 Jan 1970 00:00:00 GMT
 Connection: close
 Content-Length: 13
 Location: http://lawfilter.ertelecom.ru

#153 (closed) has some good examples of some Russian ASes blocking torproject.org and protonmail.com temporarily at least.

I've been thinking a bit about this. Depending on how the censorship is implemented we might actually be able to do something. Taking the two Aramis relays in #153 (closed) blocking protonmail.com it seems requesting https://185.70.42.12 is fine (module the TLS cert warning) and we can reach Protonmail that way. Thus, I assume the censoring is implemented via the ISPs DNS resolver. One way to work around such a censor might be to ask exit operators to not use the ISPs resolver. I'll try that out with torix's two relays.

What we know so far is that just using Unbound does not resolve the problem. Additionally, making sure external services like Google's/Cloudflare's DNS resolvers are used does not help either. It remains to be seen whether DNS over TLS would help to bypass the censorship, though.

added Roadmap::Future label and removed Backlog label

We got another report today that it was not possible to request gate.io via 81FAC66C91F57955FE6376FABA21849AC608FF17. It seems to be hosted in .it (at AS24806) and trying to access gate.io is triggering a forbidden page allegedly coming from Italian authorities.

Georg Koppen (@gk):

Georg Koppen commented:

We got another report today that it was not possible to request gate.io via 81FAC66C91F57955FE6376FABA21849AC608FF17. It seems to be hosted in .it (at AS24806) and trying to access gate.io is triggering a forbidden page allegedly coming from Italian authorities.

One lands at 85.18.219.195 and then gets a

HTTP/1.1 301 Moved Permanently
Connection: close
Location: https://warning1.consob.it

mentioned in issue #339 (closed)

See: #339 (closed) for an interesting example of exit nodes failing to resolve t.me intermittently.

We got a bunch of 302s and 307s for https://metrics.torproject.org/rs.html#details/3165EB46F1731710EBEFEB7DC47A96B78650C750 when trying to reach facebook.com. That node seems to be at an Russian ISP (Adman LLC, AS57494). DNS resolution seems to be fine, though:

2024-01-30 14:20:49,830 modules.dnsresolution [DEBUG] <https://metrics.torproject.org/rs.html#details/3165EB46F1731710EBEFEB7DC47A96B78650C750> resolved domain facebook.com to 157.240.253.35

Thus, the blocking happens at a different layer.

Requesting other domains like torproject.org seems to be fine, though...

Today @gus discovered an exit relay in Italy: https://metrics.torproject.org/rs.html#details/6796C85E7E1D547CAEC9D5CED6DE9068187288C6 intercepting outbound http requests to http://gate.io/.

The site is supposed to be hosted on AWS, but I confirmed that you get a response from a Centos server with PHP etc:

HTTP/1.1 200 OK
Date: Wed, 26 Jun 2024 19:17:29 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.4.16
X-Powered-By: PHP/5.4.16
Content-Length: 2733
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

The response body has a pile of html goo but it ends with

<h1>AVVISO</h1>
<p>L&rsquo;accesso  al presente sito &egrave; stato disabilitato in esecuzione alle disposizioni della CONSOB che impongono la inibizione dei nomi a dominio relativi ai siti web tramite cui vengono offerti servizi finanziari senza la dovuta autorizzazione.</p>
<p>Per  maggiori informazioni visiti il sito <a href="https://www.consob.it/web/area-pubblica/oscuramenti">www.consob.it/web/area-pubblica/oscuramenti</a></p>

So it looks like this relay's ISP in Italy is enforcing censorship on the website because financial arguments.

I currently don't think that it is bad enough to warrant marking the relay as a bad exit.

Opened a PR to add it to the OONI test-list for Italy: https://github.com/citizenlab/test-lists/pull/1747.

Once that PR lands you should have a bunch of data from many VPs in Italy since we have pretty good coverage over here.

It's merged and I have also bumped up the priority of the URL so we should get some decent testing of it. Check the following MAT chart (be sure to update the date as time goes by), to see which ISPs are blocking it: https://explorer.ooni.org/chart/mat?probe_cc=IT&since=2024-06-26&until=2024-06-28&time_grain=day&axis_x=measurement_start_day&axis_y=probe_asn&test_name=web_connectivity&domain=gate.io.

It seems like multiple ISPs are doing the block. If you notice some inconsistencies it's likely due to the user having chosen a custom DNS resolver, as opposed to using the official provider one (in Italy censorship is mostly implemented by having the DNS resolver of the ISP lie).

Question: Should we keep the priority high or do you have enough data now to have an informed opinion about what's going on?

See screenshot below:

Question: Should we keep the priority high or do you have enough data now to have an informed opinion about what's going on?

@art: I think the priority is not high, so please do whatever that means for you.

Today @gus discovered an exit relay in Italy: https://metrics.torproject.org/rs.html#details/6796C85E7E1D547CAEC9D5CED6DE9068187288C6 intercepting outbound http requests to http://gate.io/.

There is another similar one: https://metrics.torproject.org/rs.html#details/636380A461B814F0EF937C660A20704E78598126.

That's intercepting HTTP requests to http://bitfinex.com and http://okx.com as well. Those three sites just do not load. They seem to get redirected to some IN IP addresses (49.44.18.34 and 14.141.123.218) that block them...

mentioned in issue tpo/community/policies#25 (closed)

added Icebox label

Keep track of and deal with censorship by exit node ISPs

Child items 0

Activity