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.
@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?
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.
For me not only torproject.org and www.torproject.org are blocked, but also *.torproject.org, including gitlab.torproject.org. ISP: Domru, Krasnoyarsk.
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 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.
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.
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.