- anti-censorship-team - lists.torproject.org

Improving Snowflake performance by adjusting smux parameters
by David Fifield 04 Aug '21

04 Aug '21

While experimenting with another tunnel built on KCP and smux, I discovered that performance could be greatly increased by increasing the size of smux buffers. It's likely that doing the same can also improve performance in Snowflake. There are two relevant parameters, MaxReceiveBuffer and MaxStreamBuffer. MaxStreamBuffer seems to be the most important one to increase. https://pkg.go.dev/github.com/xtaci/smux#Config // MaxReceiveBuffer is used to control the maximum // number of data in the buffer pool MaxReceiveBuffer int // MaxStreamBuffer is used to control the maximum // number of data per stream MaxStreamBuffer int The default values are 4 MB and 64 KB. https://github.com/xtaci/smux/blob/eba6ee1d2a14eb7f86f43f7b7cb3e44234e13c66… MaxReceiveBuffer: 4194304, MaxStreamBuffer: 65536, kcptun, a prominent KCP/smux tunnel, has defaults of 4 MB (--smuxbuf) and 2 MB (--streambuf) in both client and server: https://github.com/xtaci/kcptun/blob/9a5b31b4706aba4c67bcb6ebfe108fdb564a90… In my experiment, I changed the values to 4 MB / 1 MB on the client and 16 MB / 1 MB on the server. This change increased download speed by about a factor of 3: default buffers 477.4 KB/s enlarged buffers 1388.3 KB/2 Values of MaxStreamBuffer higher than 1 MB didn't seem to have much of an effect. 256 KB did not help as much. My guess, based on intuition, is that on the server we should set a large value of MaxReceiveBuffer, as it is a global limit shared among all clients, and a relatively smaller value of MaxStreamBuffer, because there are expected to be many simultaneous streams. On the client, don't set MaxReceiveBuffer too high, because it's on an end-user device, but go ahead and set MaxStreamBuffer high, because there's expected to be only one or two streams at a time. I discovered this initially by temporarily settings smux to protocol v1 instead of v2. My understanding is that v1 lacks some kind of receive window mechanism that v2 has, and by default is more willing to expend memory receiving data. See "Per-stream sliding window to control congestion.(protocol version 2+)": https://pkg.go.dev/github.com/xtaci/smux#readme-features Past performance ticket: "Reduce KCP bottlenecks for Snowflake" https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…

3 5

Snowflake in action
by Jacobo Nájera 14 Jul '21

14 Jul '21

Hi, I wrote about my experience running snowflake proxies by standalone version. I did an analysis about hardware resources and standalone version by 4 setups. Spanish: https://www.jacobo.org/ansible-snowflake/ English: https://www.jacobo.org/en/snowflake-in-action/ More analysis soon. Thanks, Jacobo

1 0

Do we expect to have as many standalone Snowflake proxies as we do?
by David Fifield 08 Jul '21

08 Jul '21

I was looking at https://snowflake-broker.torproject.net/debug just now, and saw: current snowflakes available: 317 standalone proxies: 216 browser proxies: 0 webext proxies: 101 unknown proxies: 0 NAT Types available: restricted: 278 unrestricted: 2 unknown: 37 About 2/3 of proxies are standalone, which is more than I would have supposed. Has there been word getting out about how to run one, or something?

5 4

Question about running a snowflake proxy
by Matthew Finkel 29 Jun '21

29 Jun '21

Dropping this here in case anyone wants to answer them: https://blog.torproject.org/comment/292032#comment-292032 I'm assuming they are referring to running a standalone proxy along with obfs4proxy.

2 1

snowflake proxy operation
by Jacobo Nájera 23 Jun '21

23 Jun '21

Hi, Since the end of March I have been operating 4 snowflake proxies. So I would like to share my experience on snowflake proxy operation in numbers. Now I am looking for a reliable mechanism or method to update snowflake versions. Software details - Xen paravirtualization - Debian buster - Ansible snowflake role (https://galaxy.ansible.com/nvjacobo/snowflake) Hardware details 1. 3072 MiB (2 cores) 2. 1024 MiB (1 cores) 3. 512 MiB (1 core) 4. 512 MiB (1 core) Traffic statistics Bandwidth by proxies 1. 48.83 GiB 2. 48.83 GiB 3. 36.73 GiB 4. 28.00 GiB More details (snowflake-vnstat.txt attached) Thanks, Jacobo

2 2

Our findings from the Snowflake User Survey
by Duncan Larsen-Russell 24 May '21

24 May '21

Hi everyone, At the beginning of March we launched a social media campaign to recruit more testers of Snowflake on Tor Browser Alpha, with the intention of stress-testing the system as traffic is amped up. To collect feedback in a slightly more structured manner, the Anti-Censorship team designed a survey which ran on our LimeSurvey instance (survey.torproject.org) for the month of March and a little into April. The response was amazing, and we got over 700 submissions from Snowflake users. A lot of it involved qualitative, freeform feedback too – which isn't included in the report to protect the privacy of our participants – but has been received and read by both the Anti-Censorship and UX teams at Tor (and we're very grateful for it!). I won't spoil anything, but you can find a copy of the short report in PDF format here (direct download): https://gitlab.torproject.org/tpo/ux/research/-/raw/master/reports/2021/pub… <https://gitlab.torproject.org/tpo/ux/research/-/raw/master/reports/2021/pub…> Thank you very much to everyone who participated, and let us know if you have any questions or comments about the results! — Duncan Larsen-Russell UX Designer duncan(a)torproject.org <mailto:duncan@torproject.org>

1 0

Snowflake rendezvous design meeting 2021-05-18 14:00
by David Fifield 18 May '21

18 May '21

We'll have a meeting tomorrow to talk about redesigning changing the format of client–broker rendezvous messages, in order to support client registration methods other than domain-fronted HTTPS. To save time, this message has a proposed agenda and background information to read before the meeting. - Answer questions about background, the status quo, and future broker development goals. - Message versioning - Inside or outside JSON? - Backward compatibility with legacy-format messages. - Future need for encrypted/signed messages. - How do alternative rendezvous methods interface with the broker? - Same process or separate processes? - If separate, then how does IPC with the broker work? Convert registrations to localhost HTTP, or create some other local communication protocol? Recent work on this topic is: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Background A client sends a message to the Snowflake broker to request proxy service. See https://www.bamsoftware.com/papers/thesis/#p279 for a high-level description. Concretely, the client sends a domain-fronted HTTP POST request with a body that is a JSON serialization of an SDP offer (https://pkg.go.dev/github.com/pion/webrtc/v3#SessionDescription): https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/clien… A request looks like this: POST /client HTTP/1.1 Snowflake-NAT-Type: restricted {"type":"offer","sdp":"v=0\r\n..."} If the broker can match the client with a proxy, the response has status 200 and the body is the JSON serialization of an SDP answer: HTTP/1.1 200 OK {"type":"answer","sdp":"v=0\r\n..."} If the broker cannot make a match, the response has a status of 503 or 504, and an empty body: HTTP/1.1 503 Service Unavailable If there is a syntax problem with the client's offer, the response has status 400: HTTP/1.1 400 Bad Request The problem with the current message formats is that they rely of features of HTTP not present in other protocols, and they are not easily extensible. The HTTP bodies are assumed to contain an SDP offer/answer and that only, so any side information has to go somewhere else, such as Snowflake-NAT-Type which is sent in an HTTP header (#34129). The 200/503/400 status codes also are not present in other protocols. Parts of what is conceptually a single message are scattered across the HTTP body, header, and status code. The goal is to move all the information into a common message format that can also be used by other rendezvous channels. That means *all* the necessary information will be present in the HTTP body, and status codes will always be 200. Some past design sketches: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… When the client requests /client, the broker returns either a 200 with a response body, an empty 503, or an empty 400. This is awkward when doing rendezvous over non-HTTP channels, or even over AMP cache, which doesn't reliably pass through the server's original status code... It would be easier if all the necessary information in the broker's response were in the HTTP body, because that's easier to port to other channels. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… I propose to remove this ambiguity by including the data payload inside the JSON object that represents an error. Just like in an HTTP response, we have two things—a status code and a message—inside one package. We have already made a similar change to /proxy messages, for example changing status codes 200 and 504 to the strings "client match" and "no match": https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… https://github.com/cohosh/snowflake/pull/8/files We don't have plans to use anything other than HTTP for proxy–broker messages, so it was less important in that case to remove all reliance on HTTP. We are also generally less concerned about backward compatibility for proxies than we are for clients. cohosh has drafted a merge request that moves almost all message information into JSON in HTTP bodies: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… The above client request would become: POST /client HTTP/1.1 {"Version":"1.0","Offer":{"type":"offer","sdp":"v=0\r\n..."},"NAT":"restricted"} In the event of a match, the responses would be: HTTP/1.1 200 OK {"Answer":{"type":"answer","sdp":"v=0\r\n..."}} If no match: HTTP/1.1 200 OK {"Error":"timed out waiting for answer!"} Parsing errors currently still use an HTTP status code: HTTP/1.1 400 Bad Request This work is primarily towards the goal of supporting other rendezvous methods: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… But we also want to keep in mind other development goals for the Snowflake broker. We want to encrypt and authenticate broker messages in the future, and the message format should facilitate that, without our having to think of another backcompat scheme in the future: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… And we want to be able to move the broker away from being one big process that manages everything. Ideally, different rendezvous methods run in different processes, with reduced privileges, and can crash and be restarted independently of the main broker. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…

1 1

Branch name changes on anti-censorship team repositories
by Cecylia Bocovich 11 May '21

11 May '21

Hey everyone, We're in the process of switching to using `main` as the default branch in our repositories. I've created a ticket to document and manage this switch: https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/6 The impact to contributors will be small. Those who have already cloned the repository just need to remember to develop new patches off of the `main` branch. Merge requests in Gitlab will automatically open against the default branch, so if your MR has more commits than you expect you'll just need to rebase it onto the main branch. The hardest part is on the maintainer side since we manage so many repositories. I've tried to document all the repositories in the ticket above, but left out some very old unmaintained repos (such as pyptlib) that I don't have permission to maintain. If in the unlikely event these projects are brought back to life we can deal with a branch change then. If you think anything on or off this list is a mistake, feel free to comment on the ticket! For the procedure, I'll be running this script written by anarcat (our sysadmin): https://gitlab.com/anarcat/scripts/-/blob/main/git-branch-rename-remote The script will generally: - run `git branch --move master main` - change symbolic refs for remote: `git symbolic-ref refs/remotes/remote/HEAD \ refs/remotes/remote/main` - set local branch to track new upstream `git branch -u remote/main` - push new main branch to remote `git push -u remote main` - remove old master branch from remote: `git push -d remote master` - For GitLab, update the default branch to main My plan will be to make this change on Friday unless we realize there is more prerequisite work to do. Let me know if you have questions. Cecylia

1 1

Results of Turbo Tunnel security audit that affect Snowflake
by David Fifield 24 Apr '21

24 Apr '21

There was recently a security audit of Turbo Tunnel software artifacts, including dnstt and Snowflake. I posted the report on the dnstt page: https://www.bamsoftware.com/software/dnstt/cure53-turbotunnel-2021.pdf The report finds three issues that have to do with Snowflake, rated from Informational to Low. UCB-02-001: Memory leak in Handler() routine of Snowflake client library (Low) UCB-02-008: Lack of rate limiting in Snowflake and dnstt (Info) UCB-02-009: Brokers and proxies are not authenticated (Low) For UCB-02-001, I have already opened https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…. UCB-02-008 is not a vulnerability, but only a suggestion that rate-limiting interactions may help mitigate certain kinds of resource-exhaustion attacks. Some related tickets are: "Broker needs better resilience against DoS" https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… "Make it more expensive (CPU wise, or other thing) to make the initial connection to a snowflake" https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… UCB-02-009 is something we have already discussed in the team across various issues. I don't know if we can meaningfully authenticate proxies, but the broker's messages ought to be signed and encrypted. "End-to-end confidentiality for Snowflake client registrations" https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… "Authentication for proxy--bridge connections" https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…

1 0

Next anti-censorship reading group: 29 April 2021
by Cecylia Bocovich 22 Apr '21

22 Apr '21

Hey everyone! We will discuss "Domain Shadowing: Leveraging Content Delivery Networks for Robust Blocking-Resistant Communications" next Thursday at our regular team meeting on 2021-04-29, at 16 UTC. Relevant links: - https://www.usenix.org/system/files/sec21fall-wei.pdf Questions to ask and goals to have: - What can we learn from this work? - Are there immediate actions we can take based on this work? - Are there long-term actions we can take based on this work? - Is there future work that we want to call out, in hopes that others will pick it up? Hope to see you all there! Cecylia

1 0

2025

2024

2023

2022

2021

2020

2019

anti-censorship-team