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.
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.
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
*.www.torproject.org has just been added to the Registry of Blocked Websites, using an old court decision from 2017.
gitlab.torproject.org works.
Working mirror from EFF: https://tor.eff.org
For me not only torproject.org and www.torproject.org are blocked, but also *.torproject.org, including gitlab.torproject.org. ISP: Domru, Krasnoyarsk.
Tested with my mobile ISP (Megafon, Krasnoyarsk), gitlab.torproject.org and SNI-spoofed gitlob.torproject.org with the same IP is fine.
Thanks for the testing environment provided by @ValdikSS.
The test results show using a web-based snowflake proxy server is not sufficient for evading censorship. This result correlated with the observation that ServerHello message send by snowflake-client is dropped.
The packet capture can be obtained here:
packet.7z (4.5 KB)
Looks like there is no torproject.org in the list, only www.torproject.org and it’s subdomains like sub.www.torproject.org. But it’s ips are banned, so it will not be accessible.
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