We've been working on the Snowflake pluggable transport for Tor over the past 2 years and are getting ready to release it in stable versions of Tor Browser. Before we do this, we decided to launch a user study to encourage more Tor users to try it out, stress test the system, and get some feedback on the quality of Tor connections through Snowflake. If you have time to test it out and complete the survey, this will help us gauge the readiness of Snowflake and debug issues that may arise with a higher usage load. Details are here: http://bogdyardcfurxcle.onion/index.php/491436
Summary of Recent Developments
We've made several improvements to Snowflake over the last 2 years that have brought it from a slow, unreliable, and easily blocked transport to a large and dynamic network of volunteers. There are still more improvements to be made, but here are some highlights:
Integration of the TurboTunnel design pattern (#35)
You can read more about TurboTunnel in the related post, but this integration really allowed Snowflake to cross the threshold of being a usable pluggable transport. The ephemerality, lightweight, and P2P nature of Snowflake proxies make them less reliable than traditional Tor bridges. Thanks to this extra reliability layer, connections no longer reach an unrecoverable state if the client's Snowflake proxy goes offline.
NAT matching to connect users with compatible proxies (wiki post)
One of the issues we had to solve with matching proxies to clients was the NAT compatability of each of the peers. While STUN (a part of WebRTC) allows NAT-punching, it does not work universally for all pairs of connecting peers. Most video conferencing tools that rely on WebRTC solve this issue by routing the traffic of incompatable peers through a central TURN server. However, this is not a scalable option for a censorship resistance tool. To solve this, we partition proxies into two groups dependent on their NAT and firewall behaviour. Users with very restrictive (i.e., symmetric) NATs only receive proxies with unrestrictive NATs so that their connection is successful.
Released a webextension version of the Snowflake proxy for Firefox and Chrome(mozilla addon, chrome addon)
Over 99% of our volunteer proxies run the Snowflake web extension. It has worked extremely well in increasing the number and longevity of our volunteers. See the next section for a plot of volunteer counts over the last 6 months.
Increased our pool of STUN servers to circumvent blocking (issue)
Shortly after Snowflake became available in alpha versions of Tor Browser, we received reports that it became blocked in China. Our use of a single Google STUN server provided an easily blocked central point of failure for Snowflake. We increased the set of default STUN servers, including public STUN servers for well-known companies and organizations and Snowflake has since been unblocked.
Switched to a pure Go implementation of WebRTC for easier builds and maintenance (github.com/pion/webrtc)
This is what enabled us to build Snowflake with Tor Browser. We have kept the version of WebRTC up to date and hope that with time it will ease the burden of maintenance and the gap between the fingerprintable network differences of Snowflake and popular applications will decrease.
Our Snowflake statistics have already helped us understand and debug network issues, detect outages and failures, and tune proxy distribution. Anyone who wishes to contribute or perform research on the Snowflake network can access archived and recent metrics on users and proxies.
Size of the network and user growth
With the help of the Snowflake web extension, we've managed to grow and maintain a large network of volunteer proxies. We are currently sitting at around 7000 unique proxy IP addresses.
And the number of users has been ramping up recently as well.
Handling the increased load of users that we expect from this change will be an ongoing effort, as we learn how to scale up proxy matching. You can help us stress test the system now so we catch bugs while it's still in alpha. If you find any bugs you can open an issue in our issue tracker or our anonymous ticket reporting system. Thanks!
We've been working on the Snowflake pluggable transport for Tor over the past 2 years and are getting ready to release it in stable versions of Tor Browser. Before we do this, we decided to launch a user study to encourage more Tor users to try it out, stress test the system, and get some feedback on the quality of Tor connections through Snowflake. If you have time to test it out and complete the survey, this will help us gauge the readiness of Snowflake and debug issues that may arise with a higher usage load. Details are here: http://bogdyardcfurxcle.onion/index.php/491436
Summary of Recent Developments
We've made several improvements to Snowflake over the last 2 years that have brought it from a slow, unreliable, and easily blocked transport to a large and dynamic network of volunteers. There are still more improvements to be made, but here are some highlights:
Integration of the TurboTunnel design pattern (#35)
You can read more about TurboTunnel in the related post, but this integration really allowed Snowflake to cross the threshold of being a usable pluggable transport. The ephemerality, lightweight, and P2P nature of Snowflake proxies make them less reliable than traditional Tor bridges. Thanks to this extra reliability layer, connections no longer reach an unrecoverable state if the client's Snowflake proxy goes offline.
NAT matching to connect users with compatible proxies (wiki post)
One of the issues we had to solve with matching proxies to clients was the NAT compatability of each of the peers. While STUN (a part of WebRTC) allows NAT-punching, it does not work universally for all pairs of connecting peers. Most video conferencing tools that rely on WebRTC solve this issue by routing the traffic of incompatable peers through a central TURN server. However, this is not a scalable option for a censorship resistance tool. To solve this, we partition proxies into two groups dependent on their NAT and firewall behaviour. Users with very restrictive (i.e., symmetric) NATs only receive proxies with unrestrictive NATs so that their connection is successful.
Released a webextension version of the Snowflake proxy for Firefox and Chrome(mozilla addon, chrome addon)
Over 99% of our volunteer proxies run the Snowflake web extension. It has worked extremely well in increasing the number and longevity of our volunteers. See the next section for a plot of volunteer counts over the last 6 months.
Increased our pool of STUN servers to circumvent blocking (issue)
Shortly after Snowflake became available in alpha versions of Tor Browser, we received reports that it became blocked in China. Our use of a single Google STUN server provided an easily blocked central point of failure for Snowflake. We increased the set of default STUN servers, including public STUN servers for well-known companies and organizations and Snowflake has since been unblocked.
Switched to a pure Go implementation of WebRTC for easier builds and maintenance (github.com/pion/webrtc)
This is what enabled us to build Snowflake with Tor Browser. We have kept the version of WebRTC up to date and hope that with time it will ease the burden of maintenance and the gap between the fingerprintable network differences of Snowflake and popular applications will decrease.
Publish safely collected snowflake metrics (https://metrics.torproject.org/collector.html#snowflake-stats)
Our Snowflake statistics have already helped us understand and debug network issues, detect outages and failures, and tune proxy distribution. Anyone who wishes to contribute or perform research on the Snowflake network can access archived and recent metrics on users and proxies.
Size of the network and user growth
With the help of the Snowflake web extension, we've managed to grow and maintain a large network of volunteer proxies. We are currently sitting at around 7000 unique proxy IP addresses.
And the number of users has been ramping up recently as well.
Plans for stable deployment
We are hoping to release Snowflake in the next stable version of Tor Browser. See here for our milestone tracking this goal: https://gitlab.torproject.org/groups/tpo/-/milestones/18
Handling the increased load of users that we expect from this change will be an ongoing effort, as we learn how to scale up proxy matching. You can help us stress test the system now so we catch bugs while it's still in alpha. If you find any bugs you can open an issue in our issue tracker or our anonymous ticket reporting system. Thanks!