Goal: We (Whonix) are researching optional bridge hosting for our users to thwart web fingerprinting. Snowflake makes the most sense since no NAT hole-punching is needed. Correct me if I'm wrong here because if that was possible with obfs4 or meek it would save a lot of work.

We now know acting as a bridge makes the user act as a guard node and not just a rendezvous to one.[1]

Hi, Thanks for the email. We'reassuming you are considering this website fingerprinting defense after reading this recent blog post: https://blog.torproject.org/new-low-cost-traffic-analysis-attacks-mitigation... First, to clear up some information about Snowflake: - Volunteer Snowflakes run proxies to the bridge, *not bridges themselves*. These proxies can be run behind a NAT because clients use the built-in NAT punching properties of WebRTC to connect. The proxies then open a WebSocket connection the Snowflake bridge and relay data between the WebRTC connection with the client and the bridge. - The Snowflake bridges cannot run behind a NAT and are similar to all other existing PTs in this regard. - See https://trac.torproject.org/projects/tor/wiki/doc/Snowflakefor more information So, in order to implement use the defence referenced in the blog post in a Snowflake setting (and behind a NAT), you would have to run a Snowflake proxy and write your own client that would encapsulate your Tor traffic and send it through a TCP WebSocket connection to the Snowflake bridge. However, we do not think this will be an effective website fingerprinting defence, for reasons outlined below: 1) The defense as described in https://github.com/mikeperry-tor/vanguards/blob/master/README_SECURITY.md=#t... is meant to hide *onion service traffic*, not client exit traffic through the Tor network. So unless your intended use case is to disguise an onion service that is running behind a NAT, this defence isn't what you want. And, in fact, outside of onion services we don't yet suspect website fingerprinting of client traffic to be a severe enough threat to warrant this type of defense for internet-destined tor traffic. As the blog post states, while the attack is an improvement and points to areas where we should look for mitigations, there still are barriers to a practical attack against generic tor exit traffic. 2) Because Snowflake traffic between each client and your proxy is a distinct WebRTC connection and corresponding traffic between the proxy and the Snowflake bridge is a distinct TCP connection, it would be trivial for an adversary to filter out traffic originating from your node (i.e., your onion service traffic) from other clients' proxy traffic by simply matching up WebRTC and WebSocket flows by matching patterns of incoming and outgoing packets. The WebSocket flow that does not have a corresponding WebRTC connection will be your onion service traffic which can then be fingerprinted as easily as before. 3) We'd like to clarify that we suspect this defense to be the helpful, but it has not yet been conclusively shown to be so, and likely may not be in DPI'd bridge and/or low-traffic situations. In fact, after some discussion, we suspect that in most cases, other PT's bridge traffic will also be posible to remove from consideration, in ways beyond the simple connection matching above. To really have a chance of other traffic providing cover, client traffic needs to be mixed with concurrent relayed Tor relay traffic, which may require a relatively high speed main network relay to happen frequently enough to help. Mike has filed vanguards issue #50 (https://github.com/mikeperry-tor/vanguards/issues/50) to correct and clarify the vanguards documentation on these points.

[1] https://tor.stackexchange.com/questions/3636/what-is-the-relationship-betwee <https://tor.stackexchange.com/questions/3636/what-is-the-relationship-between-guard-nodes-and-bridges>n <https://tor.stackexchange.com/questions/3636/what-is-the-relationship-between-guard-nodes-and-bridges>-guard-nodes-and-bridges <https://tor.stackexchange.com/questions/3636/what-is-the-relationship-between-guard-nodes-and-bridges>

Some questions to help with implementation:

* Do the user's own data go through just two hops as well or are they sent to the guard node they chose before deciding to run as a bridge? How do configure Tor to do the former if it isn't?

 If you configure a bridge using the same Tor client instance, then  client-originating traffic will still use an upstream guard node, and  more hops after that. However, this has some downsides in terms of  potential stalls in all traffic during client activity, which undo some  of the benefit from having additional through traffic:  https://trac.torproject.org/projects/tor/ticket/16585  There is also some risk if the bridge extra-info descriptor can be  obtained (not sure if this is possible) due to  https://trac.torproject.org/projects/tor/ticket/8742  If you use the separated tor instance setup described in  https://github.com/mikeperry-tor/vanguards/blob/master/README_SECURITY.md#th... avoid the client-induced traffic stalling problem,  then user traffic will use one less hop, since the "Guard" position will  be taken up by the locally run but separate tor Bridge instance.  This is less of a problem for onion traffic with vanguards because there still are Layer2 vanguard nodes after that. But for non-onion traffic, users will only be using 2 hops after the local bridge. Mike will also clarify this point in the vanguards documentation.

* Are there plans to create signed debs for snowflake client/server so we can use it with Debian's tor daemon? * Do Tor Browser bundles with the snowflake addon also include the server component?

They do not. In fact, you cannot run a Snowflake proxy from Tor Browser, since Tor Browser disables WebRTC.

* Do Alpha bundles have this code yet?

Yes, alpha bundles allow you to use the Snowflake pluggable transport as a client.

* When are these bundles expected to arrive to stable?

Not sure! But soon, probably. We have a few outstanding performance considerations to tackle.

* Is it possible to interact headlessly with the snowflake server component via commandline? How?

Yes, see the instructions in the client README on the Snowflake repo: https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/client...

* How can we run TBB headlessly so users don't mistakenly interact with it on the gateway?

You can send Tor traffic (both with and without configured pluggable transports) without using Tor Browser by configuring a torrc file and running `tor -f torrc`.