Ripe Atlas 500 Russian probes SSL check result:
https://atlas.ripe.net/measurements/34271725/#probes
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.
Looks like the block affects generally Moscow users.
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.
Добрый день. У меня на корпоративном тарифе в Ростелекоме ещё с лета стал пропадал доступ к входным нодам тора. Выглядело это так: в промежутке между 11 часами утра по московскому времени и до 13 часов 1-2 раза на 15-40 минут могли быть недоступны адреса входных узлов. Netcat не мог установить соединение и ping не проходил. С любыми другими адресами, в том числе и с соседствующими с недоступными, соединения устанавливались. Проверять все входные ноды я не пробовал, однако по логу тора в этот промежуток времени не было ни одного успешного соедиения. Затем все адреса снова становились доступны. Такое могло происходить каждый день, а могло и неделями не случаться.
From the RIPE Atlas measurement, I see 16 failed probes in Moscow and 1 failed probe in Saint Petersburg:
There are 466 other probes that got the correct result, including many others in Moscow and Saint Petersburg:
@ValdikSS только что протестировал на домру и теле2 Волгоград. На домру все работает идеально, ни одной проблемы. Через теле2 не отвечает вообще НИ ОДИН мост тора.
На теле2 стоит ТСПУ, так что есть предположение, что дело именно в нём и блокируют централизованно, но пока просто тестируют, как это было во время выборов с DoH.
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
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.
A person reports that on MTS, Moscow, Tor is censored while ajax.aspnetcdn.com
domain is not.
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
…
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.
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.
Beeline Moscow
OONI Tor test: Tor censorship test result in Russia
aspnetcdn: ajax.aspnetcdn.com showed signs of TCP/IP blocking in Russia
MTS Moscow — no blocks.
OONI Tor test: Tor censorship test result in Russia
aspnetcdn: ajax.aspnetcdn.com was accessible in Russia
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)
Yes! Thanks~ This means the things being blocked is pion’s Go implementation of WebRTC, not WebRTC as a whole.
Posted some analysis of the DTLS fingerprint differences between instantio-test2.7z and 06.Dec.2021.tele2-snowflake.7z:
There are many differences, but the three differences in the Snowflake client/server fingerprint that seem most salient to me are:
- Client Hello containing a server_name (SNI) extension with an ASCII IP address. (EDIT: Being addressed in https://github.com/pion/dtls/issues/406.)
- Server sending a Hello Verify Request message. (Was also noted by MacMillan et al.)
- Lack of application_layer_protocol_negotiation (ALPN) extension in Client Hello (and hence in Server Hello).
@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.