TL;DR: We're deploying a proxy rate-limiting feature to defend against blocking attacks. No changes to proxy configurations are necessary. Make sure your Snowflake proxy is up to date. If you run multiple proxies behind the same IP address, you may see some rejected polls or a small decrease in the number of connected clients. This is expected and your proxy will continue to poll the broker and collect clients. We've been working on some features lately to improve the resilience of Snowflake to proxy enumeration attacks in which a censor can attempt to block Snowflake by blocking enough proxy IP addresses to make the system unusable. Such an attack is possible if a censor runs a modified Snowflake client and logs the IP addresses of each of the proxies it is matched with. A censor can then add these IP addresses to a block list, preventing a user in the same region from successfully connecting to those proxies. Snowflake naturally has some resistance to this type of attack because of its large proxy pool of around 150K unique IP addresses, thanks to this community <3, and high churn from many of these proxies joining and leaving the proxy pool each day[0,1]. However, high capacity standalone Snowflake proxies present a unique challenge: they are extremely useful because of their stability and generally unrestrictive or nonexistent firewalls and NATs, but they are also the most frequently matched with users and therefore are the most likely to be blocked if an enumeration attack were to occur. A few years ago, Roger posted the results of a snowflake blocking experiment[2] that found this blocking attack to be particularly effective against users behind more restrictive NATs, because these users are proportionally more likely to be matched with high capacity standalone Snowflake proxies. To help balance the distribution rates of proxies, we've designed and implemented a proxy fairness proposal[3]. In this proposal, we equalize proxy polling rates by interactively letting each proxy know when to poll next[4], and rate-limit proxies that poll too quickly[5]. You can read more about our justification for this in the linked issues, but to summarize: by slowing the rate of our higher capacity proxies to match lower capacity proxies, users are more likely to receive a proxy that is lower capacity and therefore less likely to have been enumerated. This change will also defend against a potential denial of service attack by malicious proxies flooding the network. What this means for Snowflake proxy operators: - If you are running a standalone Snowflake proxy, make sure you have the most recent version. - If you run multiple Snowflake proxies behind the same NAT, you may see some rejected polls because of the rate limiting feature. The rate limit is per-IP, intentionally, because IP addresses are what censors will block in this kind of attack. This is normal, your proxy will continue to try again. - You may or may not see a change in your usage stats. If you do, I'd love to hear from you on this thread about what you are seeing. This shouldn't affect overall capacity, but may mean that proxies reach their capacity more slowly. - There has been a change to the poll-interval command-line option. This now specifies a default or initial poll rate. The proxy's poll rate will change interactively, based on information from the Snowflake broker. We've updated the README to reflect this. We are planning a short 2 hour trial deployment of this new broker feature on Tuesday, October 27th at 15 UTC[6]. During this time you may see the above described changes take effect for your proxies. I will post an update to this thread with metrics and the outcome of this trial. If the trial goes smoothly, we will schedule a more permanent deployment of this feature. As usual, please reach out if you experience bugs or see drastic drops in connected users. Thank you for running a Snowflake proxy. The growing number of volunteers has made a huge impact on Snowflake's blocking resistance! [0] https://bamsoftware.com/papers/snowflake/#proxy-churn [1] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf... [2] https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@l... [3] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf... [4] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf... [5] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf... [6] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf...