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

#21

I wonder, are other uses of browser DTLS being filtered? For example, is a file transfer between two browsers using https://instant.io/ blocked? (Uses WebTorrent, which is WebRTC.)

I would guess that they would want to fingerprint the DTLS implementation, because that’s a known weakness in Snowflake currently. But as it appears that Client Hello is transmitted successfully, whether sent by a browser or by the custom snowflake-client software, it may be that all DTLS Server Hello is blocked.

#22

Beeline Moscow
OONI Tor test: Tor censorship test result in Russia
aspnetcdn: ajax.aspnetcdn.com showed signs of TCP/IP blocking in Russia

#23

MTS Moscow — no blocks.
OONI Tor test: Tor censorship test result in Russia
aspnetcdn: ajax.aspnetcdn.com was accessible in Russia

#24

Yes, WebRTC in browser seem to work.

It works. I’m not familiar with WebRTC, but I guess that’s fingerprint blocking.
instantio-test2.7z (661.3 KB)

#25

Yes! Thanks~ This means the things being blocked is pion’s Go implementation of WebRTC, not WebRTC as a whole.

#26

Posted some analysis of the DTLS fingerprint differences between instantio-test2.7z and 06.Dec.2021.tele2-snowflake.7z:

https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40014#note_2764715

There are many differences, but the three differences in the Snowflake client/server fingerprint that seem most salient to me are:

  1. Client Hello containing a server_name (SNI) extension with an ASCII IP address.
  2. Server sending a Hello Verify Request message. (Was also noted by MacMillan et al.)
  3. Lack of application_layer_protocol_negotiation (ALPN) extension in Client Hello (and hence in Server Hello).
#27

@Shelikhoo, @tango, if you want to test the block and circumvention techniques yourself, I can provide you access to Tele2, Beeline and Yota links. Just ask.

#28

Do I understand it right that if I enable the switch on https://snowflake.torproject.org/ page or install the extension in the browser, people will connect using my browser (and hence default WebRTC implementation which won’t be blocked) eventually?

I can ask people to do that.