A new Snowflake blocking rule (offset of supported_groups in DTLS Client Hello)

Internet censorship all around the world Russia
,
1

There’s a report by a user that Snowflake is being detected by certain byte patterns in DTLS packets:

Signature used by ru to block snowflake: \x16\xFE[\xFD\xFF] offset:0 \x00\x1D\x00\x17\x00\x18 offset:0x6e

At a first glance, this seems to be the same fingerprint as was discovered in December 2021, the presence of the supported_groups extension in Server Hello (which was a bug in the DTLS implementation):

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.

But in this case, the offset of the byte pattern appears to be targeting the Snowflake Client Hello, not the Server Hello. Presence of supported_groups in Client Hello is not a bug, but the offset of the extension is still a fingerprinting feature.

At this point there is no information about which ISPs may be affected (whether it’s one ISP, all TSPU, etc.).

2

The filter is applied for both DTLS v1.0 in record (16 fe ff), which is used by both Chrome and Firefox in ClientHello, and DTLS v1.2 in record (16 fe fd), which is used at least by Jitsi Meet, all at offset 0. Then, 1D 00 17 00 18 at 0x6f offset is checked. This is indeed different than the previous offset 0x5a (which is also blocked).
I have tested filtering only by sending the packets from Russia, not to Russia.

So, in the end, as for 19 May 2022, the filter is applied to:

Old pattern and old offset 0x5a, but with additional check for DTLS version:
16 FE [FD or FF] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1D 00 17 00 18 00

Old pattern and new offset 0x6f (used in the first ClientHello DTLS packet in Snowflake, the one without Cookie and with message sequence = 0), with additional check for DTLS version:
16 FE [FD or FF] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1D 00 17 00 18 00

There’s no explicit check for ClientHello/ServerHello, but I assume these two different offsets are needed for this exactly. Will check later.

Snowflake works fine, as it used to.

3

Thank you, that is interesting. I asked the Tor anti-censorship team to find out the offset to supported_groups produced by current versions of snowflake-client and the standalone proxy.

In February/March 2022 there was a report here about WebRTC in Chrome not working; it could be related?

4

There’s another dedicated topic for filtering WebRTC. Nobody so far had provided me an access/a link/whatsoever to reproduce the issue. All the services with WebRTC which I use work fine.