Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • T Team
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 43
    • Issues 43
    • List
    • Boards
    • Service Desk
    • Milestones
  • Packages and registries
    • Packages and registries
    • Container Registry
    • Model experiments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Anti-censorship
  • Team
  • Issues
  • #83

Creating a version of Tor Browser with patched Snowflake client that includes supported_groups censorship countermeasure

@dcf suggested that we could create a version of Tor Browser that includes Snowflake with patch applied to help users that could potentially impact by this type of censorship.

IRC Log:

[5:21:03 pm] <dcf1> Okay my discussion point is about DTLS fingerprinting in Russia
[5:21:23 pm] <+shelikhoo> yes
[5:21:35 pm] <+shelikhoo> right now, according to the vantage point we have
[5:21:57 pm] <+shelikhoo> snowflake is working in our vantage point in russia
[5:22:04 pm] <dcf1> The summary is that UDP packets matching the pattern `^\x16\xfe[\xfd\xff].{X}\x00\x1d\x00\x17\x00\x18` are getting blocked, where X is a small number of distinct offsets
[5:22:53 pm] <dcf1> My understanding is that snowflake only works in some configurations of pion/browser and client/server. Sorry, let me check my notes quick.
[5:24:05 pm] <dcf1> The concise way of saying it is: snowflake fails to connect if either side uses a Pion client.
[5:24:13 pm] <dcf1> Pion peer acts as TLS server -> ok
[5:24:19 pm] <dcf1> *DTLS
[5:24:25 pm] <dcf1> Browser peer acts as DTLS client -> ok
[5:24:37 pm] <dcf1> Pion peer acts as DTLS client -> not ok
[5:25:01 pm] <dcf1> Pion peer could be snowflake-client, or could be proxy-go.
[5:25:30 pm] <dcf1> The choice of whether a user's snowflake-client acts as a DTLS client or server may depend on their NAT
[5:25:41 pm] <dcf1> So the blocking rule may affect some NAT types more than others
[5:26:23 pm] <dcf1> Another way of stating the above rule is: snowflake only works if using a browser proxy (not a proxy-go proxy), and only if snowflake-client takes the DTLS server role in the connection
[5:27:11 pm] <dcf1> ValdikSS has a pull request with pion https://github.com/pion/dtls/pull/474 to change up the supported_groups extension that is part of the matching rule
[5:27:31 pm] <dcf1> I'm not so sure about this idea, because it may make the snowflake fingerprint even more distinctive
[5:27:58 pm] <+arma2> shelikhoo: sounds like we might want to split the vantage point test into several tests, where we try various types of snowflake proxies
[5:28:27 pm] <dcf1> One thought I had was to insert a padding or other no-op extension to adjust the offsets. that would create a new fingerprint too, but is probably less work to implement and more agile
[5:29:33 pm] <dcf1> There is perhaps no need for urgent action on this, but I am wondering if there is some class of users for whom snowflake is completely blocked. maybe, maybe not
[5:29:39 pm] <+shelikhoo> dcf1: yes, and we would need a world wide deployment of this for the snowflake proxy
[5:29:52 pm] <dcf1> shelikhoo: no, not necessarily.
[5:30:56 pm] <dcf1> If we patch snowflake-client, that takes care of one end of the connection. If the blocking rule was "Pion client", and it happened that all of a certain class of users were *always* clients, then altering the Pion fingerprint on the client side alone could be sufficient
[5:31:54 pm] <dcf1> One way forward would be to (temporarily) fork pion/dtls in the Tor Browser alpha. Then we could ask users to try the alpha release. Or even a one-off special build of the browser like we sometimes do.
[5:32:25 pm] <+shelikhoo> arma2: I think right now we don't have a way to specify whether a WebRTC peer is a client or server
[5:32:41 pm] <+shelikhoo> but I can look into this
[5:33:06 pm] <+shelikhoo> dcf1: Yes. we can try to create a version of snowflake-client with the patch applied
[5:33:08 pm] <dcf1> https://gitweb.torproject.org/builders/tor-browser-build.git/commit/?id=7ffd69a21b8a408a2be9cfdbe7401e1a7f974310
[5:33:12 pm] <+shelikhoo> and see how it works
[5:33:20 pm] <dcf1> ^ example of when we temporarily forked pion/dtls before
[5:34:55 pm] <dcf1> https://archive.org/details/@torproject
[5:35:02 pm] <dcf1> https://archive.org/details/snowflake-ru_snowflake_fix-20211208-ae7cc478fd34
[5:35:07 pm] <dcf1> https://archive.org/details/tor-browser-snowflake-ampcache-10.5.3
[5:35:17 pm] <dcf1> ^ examples of one-off Tor Browser builds made for testing
[5:36:37 pm] <dcf1> That is all from me on this topic, I just wanted to refresh awareness of it
[5:36:41 pm] <+shelikhoo> I will create a ticket for creating an specialized version of snowflake with this patch applied
[5:36:52 pm] <+shelikhoo> is there such a ticket already?
[5:37:23 pm] <dcf1> not that I'm aware, there is only https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40030 for the general observation of blocking
[5:37:24 pm] [+zwiebelbot] tor:tpo/anti-censorship/censorship-analysis#40030: IRC Tip about Signature used to block Snowflake in Russia, 2022-May-16 - https://bugs.torproject.org/tpo/anti-censorship/censorship-analysis/40030
[5:38:30 pm] <+shelikhoo> No, I think I can create one. It should give this issue more visibility
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking