OONI reports of Tor blocking in certain ISPs since 2021-12-01

Internet censorship all around the world Russia
1

Via @gus, OONI reports in a limited number of ASes in Russia show Tor blocking (blocking of all directory authorities and default obfs4 bridges) since 2021-12-01. This is unusual—the measurements from the days before do not show signs of Tor blocking.

https://explorer.ooni.org/search?until=2021-12-03&since=2021-11-29&probe_cc=RU&test_name=tor

Here are all the ASes in the past 2 days that show anomalous measurements: 0/15 Tor Browser Bridges, 0/10 Tor Directory Authorities. (Select “Status: Anomalies” in the OONI Explorer to see.)

AS ISP sample anomaly report
8359 MTS 2021-12-01 18:37:52
12389 Rostelecom 2021-12-02 09:28:31
12714 NetByNet 2021-12-01 15:35:13
12958 Tele2 2021-12-01 11:22:59
15582 Akado-Stolitsa 2021-12-01 23:59:15
16345 Beeline 2021-12-01 23:35:33
25159 MegaFon 2021-12-01 23:30:01

Here is a sampling of ASes (not all of them) that had normal measurements: 13/15 Tor Browser Bridges, 10/10 Tor Directory Authorities.

Note that AS 12389 of Rostelecom is in the above blocked list, but that AS and other ASes of Rostelecom are also in the below unblocked list. Also note that AS 16345 is in both lists—there was one normal measurement for this AS, but about 30 blocked ones.

AS ISP sample normal report
12389 Rostelecom 2021-12-02 22:56:07
12668 KomTehCentr 2021-12-02 23:17:03
16345 Beeline 2021-12-02 22:09:15
21479 Rostelecom 2021-12-02 23:09:26
24955 Ufanet 2021-12-02 21:06:08
25513 Moscow city telephone network 2021-12-02 23:12:55
41275 Lovitel 2021-12-02 21:49:40
42610 Rostelecom 2021-12-02 22:09:45
51570 ER-Telecom 2021-12-02 23:53:20
2

I can confirm. Right now on cellular Tele2 Saint Petersburg SIM (as12958) Tor does not connect.

3

Tele2 Saint Petersburg SIM (as12958). Tor does not connect in any mode.
All tests were performed using Tor Browser 11.0.1.

  • Regular (unobfuscated) connection: no response to TCP SYN from multiple IPv4s.
  • obfs4 connection: no response to TCP SYN from multiple IPv4s.
  • snowflake: the connection never establishes in full and breaks after several kilobytes transferred.
  • meek-asure: no response to TCP SYN on default Meek fronting domain ajax.aspnetcdn.com:443 (yes, really, also tested with curl. Domain resolves to 152.199.19.160.).
  • obfs4 bridges requested from Tor Browser: no successful connection with 176.170.168.5, 213.135.244.242, 82.65.171.173. This is the only bridge set which Torproject returned, I’ve tried to request multiple times and also disconnected and connected again to the cellular network to change my IP.

What worked:

  • obfs4 bridges requested from bridges.torproject.org: the connection establishes successfully!
  • obfs4 bridges requested via email: the connection establishes successfully!
  • My own obfs4 bridge in Russia: the connection establishes successfully!

All pcaps and logs are in the archive: torblock-russia-03.Dec.2021-Tele2-SPb.7z (161.2 KB)

4

https://ping-admin.ru/free_test/result/16385298065b24wzs59ggs887m5v63g.html

Screenshot 2021-12-03 at 14-20-00 Бесплатная проверка доступности сайта из различных частей мира Ping-Admin Ru — мониторинг...-fs8
Screenshot 2021-12-03 at 14-20-00 Бесплатная проверка доступности сайта из различных частей мира Ping-Admin Ru — мониторинг...-fs81059×3976 499 KB

5

Cellular MTS Moscow (AS8359) does not block Tor. Tele2 AS15378 (another AS) does not block Tor.

6

At least in a single case ajax.aspnetcdn.com is blocked with DPI.
Direct HTTP/HTTPS connections to its 40.118.185.161 and 152.199.19.160 addresses generally work fine, according to ping-admin points.

https://152.199.19.160 test

https://40.118.185.161 test

https://ajax.aspnetcdn.com test — Южно-Сахалинск point can’t establish the connection to the same IP, while the previous tests were fine.

7

The situation is changing over time: Бесплатная проверка доступности сайта из различных частей мира: Ping-Admin.Ru — мониторинг сайтов и серверов. Проверка работы сайта

Screenshot 2021-12-03 at 17-14-03 Бесплатная проверка доступности сайта из различных частей мира Ping-Admin Ru — мониторинг...-fs8
Screenshot 2021-12-03 at 17-14-03 Бесплатная проверка доступности сайта из различных частей мира Ping-Admin Ru — мониторинг...-fs8857×6171 824 KB

8

Ripe Atlas 500 Russian probes SSL check result:
https://atlas.ripe.net/measurements/34271725/#probes

Screenshot_20211203_174742-fs8
Screenshot_20211203_174742-fs8750×557 16.5 KB

9

Globalcheck.net test result. I’m not confident in it — it reports that ajax.aspnetcdn.com is not accessible from cellular Beeline, MTS, MegaFon, Yota (all Moscow), and accessible only from Rostelecom.
However, I’ve performed tests to other known-working hostnames and it lists them as accessible. Strange.

Screenshot_20211203_173610-fs8
Screenshot_20211203_173610-fs81032×283 12.7 KB

Screenshot_20211203_173552-fs8
Screenshot_20211203_173552-fs81037×282 13.1 KB

Screenshot_20211203_173543-fs8
Screenshot_20211203_173543-fs81034×290 13.8 KB

Screenshot_20211203_173532-fs8
Screenshot_20211203_173532-fs81031×289 13.1 KB

Screenshot_20211203_173600-fs8
Screenshot_20211203_173600-fs81032×313 13.5 KB

10

Looks like the block affects generally Moscow users.

11

I am scared( It will not stoppng
What can I do to save the freedom? I am a simple man. I am even cannot programming.
VPN services are not usefull for me, as I think. I want to separate the traffic.

12

Добрый день. У меня на корпоративном тарифе в Ростелекоме ещё с лета стал пропадал доступ к входным нодам тора. Выглядело это так: в промежутке между 11 часами утра по московскому времени и до 13 часов 1-2 раза на 15-40 минут могли быть недоступны адреса входных узлов. Netcat не мог установить соединение и ping не проходил. С любыми другими адресами, в том числе и с соседствующими с недоступными, соединения устанавливались. Проверять все входные ноды я не пробовал, однако по логу тора в этот промежуток времени не было ни одного успешного соедиения. Затем все адреса снова становились доступны. Такое могло происходить каждый день, а могло и неделями не случаться.

13

From the RIPE Atlas measurement, I see 16 failed probes in Moscow and 1 failed probe in Saint Petersburg:

https://atlas.ripe.net/measurements/34271725/?filter=&diversity-picker=3&aggregator=&show_only=Failed

atlas-34271725-map-failed
atlas-34271725-map-failed750×500 173 KB

There are 466 other probes that got the correct result, including many others in Moscow and Saint Petersburg:

https://atlas.ripe.net/measurements/34271725/#map

atlas-34271725-map
atlas-34271725-map750×500 179 KB

14

@ValdikSS только что протестировал на домру и теле2 Волгоград. На домру все работает идеально, ни одной проблемы. Через теле2 не отвечает вообще НИ ОДИН мост тора.
На теле2 стоит ТСПУ, так что есть предположение, что дело именно в нём и блокируют централизованно, но пока просто тестируют, как это было во время выборов с DoH.

15

My guess is that Snowflake blocking is being done by fingerprinting and blocking DTLS Server Hello. In 03.Dec.2021.tele2-snowflake.pcapng, we see that HTTPS communication with the Snowflake broker is successful, as are the STUN negotiations with proxies. Then there are several exchanges of:

client -> Client Hello
          Hello Verify Request <- proxy
client -> Client Hello
client -> Client Hello
client -> Client Hello
client -> Client Hello
client -> Client Hello
client -> Client Hello
client -> Client Hello
client -> Client Hello
client -> Client Hello

with different proxy IP addresses. It is as if the Server Hello is never reaching the client. Then, there is an exchange in the opposite direction, where a proxy tries to send a Client Hello to the Snowflake client. In this case, the Snowflake client sends multiple Server Hello, but the proxy does not respond to them:

                  Client Hello <- proxy
client -> Hello Verify Request
client -> Hello Verify Request
                  Client Hello <- proxy
client -> Server Hello
client -> Server Hello
client -> Server Hello
client -> Server Hello
client -> Server Hello
client -> Server Hello
client -> Server Hello
client -> Server Hello
client -> Server Hello
client -> Server Hello
16

The Tor Project community team has posted a guide, in Russian, that explains how to get a private obfs4 bridge.

You will have to replace the sample obfs4 1.2.3.4:1234 line with a real working bridge line that you get from Tor Browser’s “Request a bridge from torproject.org” / “Запросить мост у torproject.org” feature. You can also get a bridge line from bridges.torproject.org or by emailing bridges@torproject.org from a Gmail address.

If you need more help, you can email frontdesk@torproject.org.

17

A person reports that on MTS, Moscow, Tor is censored while ⁨ajax.aspnetcdn.com⁩ domain is not.

18

YOTA

Summary: All TCP traffic towards IP addresses of Tor nodes and ajax.aspnetcdn.com is blocked on router (SYN receive no reply regardless of TTL). UDP and ICMP traffic is not blocked.

traceroute --tcp --port=443 154.35.175.225 
$ sudo traceroute --tcp --port=443 154.35.175.225
traceroute to 154.35.175.225 (154.35.175.225), 30 hops max, 60 byte packets
 1  _gateway (192.168.14.1)  1.031 ms  2.427 ms  2.408 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
…

If we tcp-ping a very close neighbor IP address 154.35.175.224, it pings.

traceroute --tcp --port=443 154.35.175.224 
$ sudo traceroute --tcp --port=443 154.35.175.224
traceroute to 154.35.175.224 (154.35.175.224), 30 hops max, 60 byte packets
 1  _gateway (192.168.14.1)  1.089 ms  3.542 ms  3.513 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  37.29.105.81 (37.29.105.81)  74.553 ms  86.881 ms  61.471 ms
11  83.169.204.112 (83.169.204.112)  135.780 ms  115.363 ms 83.169.204.116 (83.169.204.116)  94.330 ms
12  83.169.204.70 (83.169.204.70)  86.984 ms  79.724 ms  64.736 ms
13  war-b3-link.ip.twelve99.net (195.12.255.204)  75.706 ms  83.467 ms  88.466 ms
14  hbg-bb4-link.ip.twelve99.net (62.115.118.40)  87.974 ms  100.923 ms  107.544 ms
15  ddf-b2-link.ip.twelve99.net (62.115.115.51)  72.799 ms  70.355 ms  73.094 ms
16  gtt-ic340298-ddf-b2.ip.twelve99-cust.net (62.115.169.81)  73.945 ms  74.145 ms  80.880 ms
17  ae36.cr1-chi1.ip4.gtt.net (89.149.141.165)  181.282 ms  185.423 ms  193.968 ms
…

UDP and ICMP is not blocked.

traceroute --udp --port=443 154.35.175.225 
$ sudo traceroute --udp --port=443 154.35.175.225
traceroute to 154.35.175.225 (154.35.175.225), 30 hops max, 60 byte packets
 1  _gateway (192.168.14.1)  0.720 ms  1.747 ms  1.724 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  37.29.105.81 (37.29.105.81)  64.332 ms  88.765 ms  74.867 ms
11  83.169.204.112 (83.169.204.112)  113.846 ms  134.836 ms 83.169.204.116 (83.169.204.116)  92.758 ms
12  83.169.204.74 (83.169.204.74)  95.115 ms 83.169.204.70 (83.169.204.70)  80.697 ms  65.303 ms
13  war-b3-link.ip.twelve99.net (195.12.255.204)  72.108 ms  77.991 ms  81.949 ms
14  hbg-bb4-link.ip.twelve99.net (62.115.118.40)  88.956 ms  99.532 ms  101.905 ms
15  ddf-b2-link.ip.twelve99.net (62.115.115.51)  66.823 ms  68.714 ms  70.443 ms
16  gtt-ic340298-ddf-b2.ip.twelve99-cust.net (62.115.169.81)  74.701 ms  74.677 ms  75.864 ms
17  ae36.cr1-chi1.ip4.gtt.net (89.149.141.165)  180.778 ms  185.716 ms  164.883 ms
18  as14987.xe-3-0-0.ar1.ord6.us.as4436.gtt.net (69.31.110.70)  169.592 ms  174.838 ms  168.728 ms
…

TELE2

Exactly the same as on Yota: TCP is filtered, UDP and ICMP works.

traceroute --tcp --port=443 154.35.175.225 
$ sudo traceroute --tcp --port=443 154.35.175.225
traceroute to 154.35.175.225 (154.35.175.225), 30 hops max, 60 byte packets
 1  _gateway (192.168.43.209)  2.072 ms  2.077 ms  2.151 ms
 2  * * *
 3  10.221.3.197 (10.221.3.197)  49.470 ms  49.461 ms  49.452 ms
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
…
traceroute --udp 154.35.175.225 
$ sudo traceroute --udp 154.35.175.225
traceroute to 154.35.175.225 (154.35.175.225), 30 hops max, 60 byte packets
 1  _gateway (192.168.43.209)  2.146 ms  2.106 ms  2.987 ms
 2  * * *
 3  10.221.3.197 (10.221.3.197)  35.789 ms  38.249 ms  36.699 ms
 4  10.221.7.113 (10.221.7.113)  33.829 ms  33.811 ms  33.799 ms
 5  10.221.7.126 (10.221.7.126)  38.176 ms  38.163 ms  38.145 ms
 6  10.221.66.142 (10.221.66.142)  34.101 ms  28.898 ms  28.865 ms
 7  * * *
 8  broadband-90-154-105-25.ip.moscow.rt.ru (90.154.105.25)  39.224 ms  39.213 ms  42.975 ms
 9  87.226.133.75 (87.226.133.75)  60.395 ms 185.140.148.27 (185.140.148.27)  58.617 ms  57.688 ms
10  ae1-500.cr1-stk3.ip4.gtt.net (77.67.90.96)  79.596 ms  79.577 ms  77.837 ms
11  ae36.cr1-chi1.ip4.gtt.net (89.149.141.165)  183.412 ms  187.280 ms  178.787 ms
12  as14987.xe-3-0-0.ar1.ord6.us.as4436.gtt.net (69.31.110.70)  175.081 ms  161.543 ms  161.505 ms
traceroute --tcp --port=443 154.35.175.224 
$ sudo traceroute --tcp --port=443 154.35.175.224
traceroute to 154.35.175.224 (154.35.175.224), 30 hops max, 60 byte packets
 1  _gateway (192.168.43.209)  11.726 ms  11.792 ms  11.916 ms
 2  * * *
 3  10.221.2.197 (10.221.2.197)  55.413 ms  56.740 ms  56.729 ms
 4  10.221.7.113 (10.221.7.113)  53.513 ms  53.502 ms  53.590 ms
 5  10.221.7.122 (10.221.7.122)  54.237 ms  54.355 ms  55.188 ms
 6  * * *
 7  * * *
 8  broadband-90-154-105-25.ip.moscow.rt.ru (90.154.105.25)  30.587 ms  29.964 ms  29.957 ms
 9  185.140.148.27 (185.140.148.27)  51.525 ms  51.471 ms  50.032 ms
10  ae1-500.cr1-stk3.ip4.gtt.net (77.67.90.96)  75.430 ms  64.510 ms  70.755 ms
11  ae36.cr1-chi1.ip4.gtt.net (89.149.141.165)  169.236 ms  160.956 ms  169.096 ms
…
19

You’re right. Here’s the new dump.
06.Dec.2021.tele2-snowflake.7z (179.8 KB)

20

Does WebRTC work in browser?

If it still work in browser, then the fingerprint being recognized is the pion WebRTC library, not WebRTC as a whole. It would be possible to evade this blocking by using a browser to forward the traffic.