[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-relays] Proxy fairness improvements in Snowflake
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/snowflake/-/work_items/40494
[2]
https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@xxxxxxxxxxxxxxxxxxxx/message/T2G7AUYTXI2RZJIT3QRHYLAHKSYFUMNH/
[3]
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/work_items/40507
[4]
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/work_items/25598
[5]
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/work_items/40506
[6]
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/work_items/40573
_______________________________________________
tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx