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

#29

It depends—possibly not. The issue is that the client side of the connection does not use a browser, but a specialized program called snowflake-client, which uses pion/webrtc, an independent WebRTC implementation. pion/webrtc ultimately depends on pion/dtls, which is what is being fingerprinted.

There’s a further complication, which is that there are two implementations of the WebRTC proxy side: the web version that runs in a page or as a browser extension, and a standalone command-line version. The web version uses browser WebRTC and therefore probably has a good fingerprint, but the standalone version uses the same pion/webrtc package. So two configurations occur in practice, pion–browser and pion–pion, and it’s conceivable that one of the configurations works while the other does not.

You can find recent Snowflake metrics at Sources – Tor Metrics (and archived ones at Sources – Tor Metrics). They show the counts of each type of proxy over 24 hours. I think there are currently sufficiently many web proxies (snowflake-ips-badge + snowflake-ips-webext). The area where we have more difficulty is getting proxies with compatible NATs—client-restricted-denied-count counts how many times a client requested a proxy but could not be served because there was no proxy available with a compatible NAT. I think most of those clients eventually get service, it just takes longer.

@type snowflake-stats 1.0
snowflake-stats-end 2021-12-06 20:26:47 (86400 s)
snowflake-ips US=3884,DE=1470,RU=1082,FR=691,GB=522,JP=479,CA=384,BR=355,NL=344,...
snowflake-ips-total 13963
snowflake-ips-standalone 3865
snowflake-ips-badge 69
snowflake-ips-webext 10029
snowflake-idle-count 3126880
client-denied-count 84104
client-restricted-denied-count 84104
client-unrestricted-denied-count 0
client-snowflake-match-count 281448
snowflake-ips-nat-restricted 8017
snowflake-ips-nat-unrestricted 210
snowflake-ips-nat-unknown 5697