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
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.
ping-admin results of Tor relay IP addresses which have HTTP server on port 80:
184.108.40.206 Бесплатная проверка доступности сайта из различных частей мира: Ping-Admin.Ru — мониторинг сайтов и серверов. Проверка работы сайта
220.127.116.11 Бесплатная проверка доступности сайта из различных частей мира: Ping-Admin.Ru — мониторинг сайтов и серверов. Проверка работы сайта
18.104.22.168 Бесплатная проверка доступности сайта из различных частей мира: Ping-Admin.Ru — мониторинг сайтов и серверов. Проверка работы сайта
22.214.171.124 Бесплатная проверка доступности сайта из различных частей мира: 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 126.96.36.199 … % Information related to '188.8.131.52/16AS25513' route: 184.108.40.206/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
$ curl 220.127.116.11 <html> <head><title>301 Moved Permanently</title></head> <body> <center><h1>301 Moved Permanently</h1></center> <hr><center>openresty/18.104.22.168</center> </body> </html>
# curl 22.214.171.124 --connect-timeout 5 -v * Trying 126.96.36.199:80... * Connection timed out after 5000 milliseconds * Closing connection 0 curl: (28) Connection timed out after 5000 milliseconds
$ whois 188.8.131.52 … role: Hosting technology LTD address: 1-st Frezernaya str. 2/1 korp. 2 admin-c: SK10337-RIPE tech-c: SK10337-RIPE abuse-mailbox: firstname.lastname@example.org 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
# curl 184.108.40.206 --connect-timeout 5 -v * Trying 220.127.116.11: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:
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.