[tor-dev] Snowflake server and traffic analysis questions

[Cecylia Bocovich]

> 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-mitigations

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=#the-best-way-to-run-tor-relays-or-bridges-with-your-service
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#the-best-way-to-run-tor-relays-or-bridges-with-your-serviceto
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/README.md?id=3D6077141f4affdab9b7ce97a9b1c6859825eaaa29

> * 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`.