Strange, in my case - only www.torproject.org isn’t working.
Tried to modify Snowflake (pion webrtc library) fingerprint.
- I tried to change ciphersuites and its order, as well as signatures and its order — did not help, no connection.
- Snowflake certificate does include KU, EKU, BC and SKI extensions, while Firefox has none.
snowflake-tests-moddedversion.7z (223.7 KB)
- Tried to remove extensions, x509 library in golang seems not to allow that completely, there’s still empty (0-byte) extension field added.
Did not help, no connection.
Also, certificate serial ID in snowflake is much lengthy than a Firefox has.
snowflake-test3-emptyextensions.7z (186.5 KB)
All right, finally managed to circumvent Snowflake censorship.
Russian DPI check supported_groups extension in ServerHello payload (byte 0x5a in udp packet).
It looks for DTLS packet header “magic” “16 FE FD” and then looks for “1D 00 17 00 18” at 0x5a offset.
Here’s the minimal UDP payload which triggers the filtering:
russian-filtered-serverhello.bin.7z (193 Bytes)
Just remove any one of 3 groups here: dtls/flight4handler.go at v2.0.8 · pion/dtls · GitHub
Recompiled snowflake (windows, linux) with modification:
snowflake-russian-censorship-circumvention-08.12.2021.7z (3.5 MB)
However, the filtering is bi-directional, that’s why ServerHello from unmodified standalone servers is still being filtered. However, Tor successfully connects over Snowflake with browser servers.
PCAP: snowflake-changedsupportedgroups_circumvention.7z (283.9 KB)
It is worth noting that in the browser version of WebRTC connection, there is no supported_groups extension as shown in the instant_io packet capture.
Look’s like subdomains also isn’t available.
Yesterday it was *.www.torproject.org in the blacklist, now it’s *.torproject.org
So yeah, subdomains now should be also blocked everywhere. Tested gitlab.torproject.org on my mobile ISP, now it’s blocked, while it wasn’t yesterday.
The relays, bridges, ajax.aspnetcdn.com and Snowflake block has been lifted. Tor browser connects just fine without any circumvention (tested on Beeline and Tele2).
The website is now blocked by the official Registry record.
Today the blocking returned, now it affect more ISPs.
Here’s the block on MGTS, Moscow: Tor censorship test result in Russia
There’s also Psiphon censorship, according to OONI Probe.
Beeline: Psiphon was NOT reachable in Russia
MGTS: Psiphon was NOT reachable in Russia
Psiphon:
Domru, Krasnoyarsk - unreachable: Psiphon was NOT reachable in Russia
Megafon, Krasnoyarsk - unreachable: Psiphon was NOT reachable in Russia
ping-admin results of Tor relay IP addresses which have HTTP server on port 80:
97.70.74.194 Бесплатная проверка доступности сайта из различных частей мира: Ping-Admin.Ru — мониторинг сайтов и серверов. Проверка работы сайта
104.238.167.111 Бесплатная проверка доступности сайта из различных частей мира: Ping-Admin.Ru — мониторинг сайтов и серверов. Проверка работы сайта
135.125.55.228 Бесплатная проверка доступности сайта из различных частей мира: Ping-Admin.Ru — мониторинг сайтов и серверов. Проверка работы сайта
162.243.72.198 Бесплатная проверка доступности сайта из различных частей мира: Ping-Admin.Ru — мониторинг сайтов и серверов. Проверка работы сайта
@libneko checked Psiphon app just now on my ISPs
I agree there is block
On Domru Volgograd (No tspu) all works
On Tele2 Volgograd Moscow IP (Tspu) don’t work, or connects after 5 minutes minimum
@ValdikSS can’t take dumps now, sorry, but seems its related to tspu, so could u check?
I’ve scanned several Tor relay IP addresses which are hosted in Russia and have 80 port opened.
They are not reachable from the ISP with Tor block (Tele2/Yota/Beeline).
$ whois 95.165.148.12
…
% Information related to '95.165.0.0/16AS25513'
route: 95.165.0.0/16
descr: Moscow Local Telephone Network (OAO MGTS)
descr: Moscow, Russia
origin: AS25513
mnt-by: MGTS-USPD-MNT
created: 2009-01-27T13:52:05Z
last-modified: 2009-01-27T13:52:05Z
source: RIPE
Regular link:
$ curl 95.165.148.12
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>openresty/1.19.3.2</center>
</body>
</html>
Beeline:
# curl 95.165.148.12 --connect-timeout 5 -v
* Trying 95.165.148.12:80...
* Connection timed out after 5000 milliseconds
* Closing connection 0
curl: (28) Connection timed out after 5000 milliseconds
Another example:
$ whois 62.113.113.56
…
role: Hosting technology LTD
address: 1-st Frezernaya str. 2/1 korp. 2
admin-c: SK10337-RIPE
tech-c: SK10337-RIPE
abuse-mailbox: abuse@vdsina.ru
nic-hdl: HTL31-RIPE
mnt-by: ru-vdsina-1-mnt
created: 2018-02-19T16:32:26Z
last-modified: 2018-02-19T16:32:26Z
source: RIPE # Filtered
Beeline:
# curl 62.113.113.56 --connect-timeout 5 -v
* Trying 62.113.113.56:80...
* Connection timed out after 5001 milliseconds
* Closing connection 0
curl: (28) Connection timed out after 5001 milliseconds
There’s definitely filtering involved.
For some reason, Psiphon on Domru is now fine, while TOR on Megafon is even more degraded:
Now: Tor censorship test result in Russia
Was: Tor censorship test result in Russia
The filtering towards IP addresses of Tor relays is in effect in Moscow, Tomsk (Zelenaya Tochka TOMSK LLC), Penza (ER-Telecom), Perm (ER-Telecom), Medvedevo (ER-Telecom), Khabarovsk (Transtelecom), Kemerovo (Regional Information Technologies Ltd.), UFA (JSC Ufanet), Ulyanovsk (MTS), Kazan (two unnamed ISP), Novosibirsk (Sibirskie Seti, Truenetwork), Armavir (CityTelekom), Chita (Chitatehenergy), Omsk (RusHost), Voronezh (Transtelecom), Volzhskiy.
Latest RIPE Atlas measurements (sort by “majority” and watch for timeouts)
Is the block on ajax.aspnetcdn.com still present? In the OONI web connectivity test, I see anomalies between 2021-12-01 and 2021-12-08, but the most recent anomaly is 2021-12-08 13:07, and there are many “accessible” measurements since then.
Yes, it is still getting blocked, but only on some ISP. Not accessible in Moscow from Beeline, Tele2, Yota, but people report from other cities that ajax.aspnetcdn.com works but Tor relays do not.