IRC Tip about Signature used to block Snowflake in Russia, 2022-May-16
[2:46:20 pm] <blocked> Signature used by ru to block snowflake: \x16\xFE[\xFD\xFF] offset:0 \x00\x1D\x00\x17\x00\x18 offset:0x6e
[2:59:08 pm] <+ggus> cohosh: shelikhoo: ^[3:30:38 pm] <shelikhoo> blocked: is there any context about this signature, like which ISP/network environment this kind block is observed?
[3:37:11 pm] <+armadev> (blocked left the channel)
[3:47:16 pm] <+armadev> cohosh: and dcf even commented on the ticket just now
[3:47:26 pm] <+armadev> (looks like the same signature as 5 months ago, he says)Designs
- tpo/anti-censorship/pluggable-transports/snowflake #40140
Activity
\x16\xFE[\xFD\xFF]offset:0\x00\x1D\x00\x17\x00\x18offset:0x6eExcept for an offset, this looks the same as what @ValdikSS found 5 months ago:
tpo/anti-censorship/pluggable-transports/snowflake#40014 (comment 2765074)
Russian DPI check supported_groups extension in ServerHello payload (byte 0x5a in udp packet). It looks for DTLS packet header "magic"
16 FE FDand then looks for1D 00 17 00 18at 0x5a offset.0x001d, 0x0017, 0x0018 are x25519, secp256r1, secp384r1.
The snowflake-client in any recent version of Tor Browser should not have this signature. Maybe there are command-line proxies that have not upgraded, and are still sending supported_groups in Server Hello, and that is what the IRC commenter is referring to?
I failed to request additional context information about the tip in the irc. The commenter left before I was given the chance to ask.....
[3:30:38 pm] <shelikhoo> blocked: is there any context about this signature, like which ISP/network environment this kind block is observed? [3:37:11 pm] <+armadev> (blocked left the channel) ```
blocked returned to IRC and pasted this:
blocked
Datagram Transport Layer Security DTLSv1.2 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: DTLS 1.2 (0xfefd) Epoch: 0 Sequence Number: 0 Length: 124 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 112 Message Sequence: 0 Fragment Offset: 0 Fragment Length: 112 Version: DTLS 1.2 (0xfefd) Random: <snip>... GMT Unix Time: <snip> UTC Random Bytes: <snip>... Session ID Length: 0 Cookie Length: 0 Cipher Suites Length: 12 Cipher Suites (6 suites) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 58 Extension: signature_algorithms (len=16) Type: signature_algorithms (13) Length: 16 Signature Hash Algorithms Length: 14 Signature Hash Algorithms (7 algorithms) Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503) Signature Hash Algorithm Hash: SHA384 (5) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603) Signature Hash Algorithm Hash: SHA512 (6) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: rsa_pkcs1_sha256 (0x0401) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: rsa_pkcs1_sha384 (0x0501) Signature Hash Algorithm Hash: SHA384 (5) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: rsa_pkcs1_sha512 (0x0601) Signature Hash Algorithm Hash: SHA512 (6) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: ed25519 (0x0807) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (7) Extension: renegotiation_info (len=1) Type: renegotiation_info (65281) Length: 1 Renegotiation Info extension Renegotiation info extension length: 0 Extension: supported_groups (len=8) Type: supported_groups (10) Length: 8 Supported Groups List Length: 6 Supported Groups (3 groups) Supported Group: x25519 (0x001d) Supported Group: secp256r1 (0x0017) Supported Group: secp384r1 (0x0018) Extension: ec_point_formats (len=2) Type: ec_point_formats (11) Length: 2 EC point formats Length: 1 Elliptic curves point formats (1) EC point format: uncompressed (0) Extension: use_srtp (len=7) Type: use_srtp (14) Length: 7 SRTP Protection Profiles Length: 4 SRTP Protection Profile: SRTP_AEAD_AES_128_GCM (0x0007) SRTP Protection Profile: SRTP_AES128_CM_HMAC_SHA1_80 (0x0001) MKI Length: 0 Extension: extended_master_secret (len=0) Type: extended_master_secret (23) Length: 0Works
Datagram Transport Layer Security DTLS Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: DTLS 1.0 (0xfeff) Epoch: 0 Sequence Number: 0 Length: 176 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 164 Message Sequence: 0 Fragment Offset: 0 Fragment Length: 164 Version: DTLS 1.2 (0xfefd) Random: <snip>... GMT Unix Time: <snip> UTC Random Bytes: <snip>... Session ID Length: 0 Cookie Length: 0 Cipher Suites Length: 16 Cipher Suites (8 suites) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9) Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 106 Extension: extended_master_secret (len=0) Type: extended_master_secret (23) Length: 0 Extension: renegotiation_info (len=1) Type: renegotiation_info (65281) Length: 1 Renegotiation Info extension Renegotiation info extension length: 0 Extension: supported_groups (len=8) Type: supported_groups (10) Length: 8 Supported Groups List Length: 6 Supported Groups (3 groups) Supported Group: x25519 (0x001d) Supported Group: secp256r1 (0x0017) Supported Group: secp384r1 (0x0018) Extension: ec_point_formats (len=2) Type: ec_point_formats (11) Length: 2 EC point formats Length: 1 Elliptic curves point formats (1) EC point format: uncompressed (0) Extension: application_layer_protocol_negotiation (len=18) Type: application_layer_protocol_negotiation (16) Length: 18 ALPN Extension Length: 16 ALPN Protocol ALPN string length: 6 ALPN Next Protocol: webrtc ALPN string length: 8 ALPN Next Protocol: c-webrtc Extension: signature_algorithms (len=32) Type: signature_algorithms (13) Length: 32 Signature Hash Algorithms Length: 30 Signature Hash Algorithms (15 algorithms) Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503) Signature Hash Algorithm Hash: SHA384 (5) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603) Signature Hash Algorithm Hash: SHA512 (6) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: ecdsa_sha1 (0x0203) Signature Hash Algorithm Hash: SHA1 (2) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: rsa_pss_rsae_sha256 (0x0804) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (4) Signature Algorithm: rsa_pss_rsae_sha384 (0x0805) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (5) Signature Algorithm: rsa_pss_rsae_sha512 (0x0806) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (6) Signature Algorithm: rsa_pkcs1_sha256 (0x0401) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: rsa_pkcs1_sha384 (0x0501) Signature Hash Algorithm Hash: SHA384 (5) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: rsa_pkcs1_sha512 (0x0601) Signature Hash Algorithm Hash: SHA512 (6) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: rsa_pkcs1_sha1 (0x0201) Signature Hash Algorithm Hash: SHA1 (2) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: SHA256 DSA (0x0402) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: DSA (2) Signature Algorithm: SHA384 DSA (0x0502) Signature Hash Algorithm Hash: SHA384 (5) Signature Hash Algorithm Signature: DSA (2) Signature Algorithm: SHA512 DSA (0x0602) Signature Hash Algorithm Hash: SHA512 (6) Signature Hash Algorithm Signature: DSA (2) Signature Algorithm: SHA1 DSA (0x0202) Signature Hash Algorithm Hash: SHA1 (2) Signature Hash Algorithm Signature: DSA (2) Extension: Unknown type 28 (len=2) Type: Unknown (28) Length: 2 Data: 4000 Extension: use_srtp (len=11) Type: use_srtp (14) Length: 11 SRTP Protection Profiles Length: 8 SRTP Protection Profile: SRTP_AEAD_AES_128_GCM (0x0007) SRTP Protection Profile: SRTP_AEAD_AES_256_GCM (0x0008) SRTP Protection Profile: SRTP_AES128_CM_HMAC_SHA1_80 (0x0001) SRTP Protection Profile: SRTP_AES128_CM_HMAC_SHA1_32 (0x0002) MKI Length: 0Okay, this may be something new. These packet dissections are for Client Hello, whereas the previous detection rule was for presence of supported_groups in Server Hello. The supported_groups extension is expected in Client Hello (whereas it was out of place in Server Hello), but a detection rule could be triggering on the offset of the extension.
The two fingerprints above are quite different: it looks like the first (non-working) is from Pion, and the second (working) is probably from a browser. They both include supported_groups with identical contents (the byte pattern
\x00\x1D\x00\x17\x00\x18), but at different offsets:Extension: supported_groups (len=8) Type: supported_groups (10) Length: 8 Supported Groups List Length: 6 Supported Groups (3 groups) Supported Group: x25519 (0x001d) Supported Group: secp256r1 (0x0017) Supported Group: secp384r1 (0x0018)It would be good to have more information about where this detection rule is being enforced—evidently it's not everywhere in Russia.
We may be able to break this specific detection rule by doing anything to disturb the offsets before the supported_groups extension appears. Adding or removing a ciphersuite would do it, for example.
Assuming that tpo/anti-censorship/pluggable-transports/snowflake#40120 (closed) is about blocking (because user dismissed suggestion about old Android), it seems to be something related to broker (TLS fingerprint? Did tpo/anti-censorship/pluggable-transports/snowflake#40054 (closed) make his way into stable TBB?).
mentioned in issue tpo/anti-censorship/pluggable-transports/snowflake#40140 (closed)
marked this issue as related to tpo/anti-censorship/pluggable-transports/snowflake#40140 (closed)
added Next label
assigned to @shelikhoo
@shelikhoo I assign this to you as you were looking into it, but feel free to unasign yourself.
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 18at 0x6f offset is checked. This is indeed different than the previous offset 0x5a (which is also blocked).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 00Old 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 00There's no explicit check for ClientHello/ServerHello, but I assume these two different offsets are needed for this exactly. Will check later.
Edited by ValdikSS-
I found another ClientHello pattern which is getting filtered, which is presumably corresponding to the older Chrome versions (91 and earlier). The filter is applied for both DTLS v1.0 in record (16 fe ff) and DTLS v1.2 in record (16 fe fd).
echo 16FEFF00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001D00170018 | xxd -ps -r > chromium-clienthello-maybe.bin00000000 16 fe ff 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000060 00 00 00 00 00 00 00 00 00 00 00 1d 00 17 00 18 |................| 00000070Edited by ValdikSS I found another ClientHello pattern which is getting filtered
I got a private message that says
\x00\x1d\x00\x17\x00\x18at any of these offsets is getting filtered:offset comment 0x50 0x54 0x59 we knew last December, tpo/anti-censorship/pluggable-transports/snowflake#40014 (comment 2765074) 0x6a the parent comment, #40030 (comment 2809143) 0x6e this issue, #40030 (closed) 0x7e 0x82 -
https://ntc.party/t/webrtc/2174/19 7 filtered packets
We discussed this issue at the anti-censorship meeting on 2022-06-16.
https://lists.torproject.org/pipermail/tor-project/2022-June/003406.html http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-06-16-15.59.log.html#l-43
- UDP packets matching the pattern
^\x16\xfe[\xfd\xff].{X}\x00\x1d\x00\x17\x00\x18are getting blocked, where X is a small number of enumerated byte offsets, and \x00\x1d\x00\x17\x00\x18 is the supported_groups extension. One of the offsets happens to match where pion/dtls places the extension in its Client Hello. - Concise description of the current situation: snowflake connections are blocked when either peer in the connection is Pion-based (e.g. snowflake-client or proxy-go) and takes the role of the DTLS client.
- Put another way, the connection is ok if: the proxy is a browser proxy (not proxy-go) and snowflake-client operates as a DTLS server, not client
- Pull request https://github.com/pion/dtls/pull/474 has the risk of creating a new, even more distinctive fingerprint
- So does altering the offset of supported_groups without changing other aspects of the fingerprint
- One idea is to make a patch or fork of pion/dtls with either pull request https://github.com/pion/dtls/pull/474 or some other change that alters the offset, then ask people to test it
- https://gitweb.torproject.org/builders/tor-browser-build.git/commit/?id=7ffd69a21b8a408a2be9cfdbe7401e1a7f974310 is a past temporary fork for a fingerprinting fix
- https://archive.org/details/snowflake-ru_snowflake_fix-20211208-ae7cc478fd34 is the resulting bundle that we asked people to test
- Shell will create a ticket for releasing a version of Snowflake/TorBrowser with patch applied
- UDP packets matching the pattern
mentioned in issue team#83 (closed)
marked this issue as related to tpo/anti-censorship/pluggable-transports/snowflake#40152 (closed)
mentioned in issue tpo/anti-censorship/pluggable-transports/snowflake#40152 (closed)
mentioned in issue tpo/anti-censorship/pluggable-transports/snowflake-webext#45 (closed)
marked this issue as related to team#83 (closed)
