Re: [tor-talk] Why are all Snowflake proxies connecting to a single bridge (flakey) instead of connecting to a normal relay of client`s choice?

[David Fifield <david@xxxxxxxxxxxxxxx>]

On Mon, Sep 14, 2020 at 05:37:53PM +0000, molterzui@xxxxxxxxxx wrote:
> Why are all Snowflake proxies connecting to a single bridge (flakey) instead
> of connecting to a normal relay of client`s choice, multiple bridges or even
> connecting  directly to the middle relay so that it serves as a first hop in
> the three hop circuit?

Using Snowflake, you can only connect to a bridge that has the Snowflake
server pluggable transport installed. It's the same with obfs4 or any
other pluggable transport. Pluggable transport protocols are generally
not compatible with the TCP/TLS OR protocol that all relays support, so
there needs to be a component on the bridge that converts from one
protocol to the other. In Snowflake, the pluggable transport connection
happens to use WebSocket, because web browsers do not support direct TCP
connections but they do support WebSocket. The bridge must know how to
unwrap the WebSocket connection and convert it back into the OR
protocol, which means installing custom software.

If there were multiple bridges with the Snowflake server pluggable
transport installed, then yes, in principle a client could connect
through a Snowflake proxy to any of those bridges. For the purposes of
circumvention (ignoring anonymity for a moment), there's no reason to
have more than one bridge. It's different from obfs4, which requires
lots of bridges because the censor slowly discovers and blocks them. The
idea of Snowflake is that the censor does not benefit from blocking the
bridge directly. We move the blocking activity to separate layer before
the bridge -- the Snowflake proxies, which are supposed to be cheaper
and easier to set up than full bridges.

One reason not to give the client full control over where to connect to
is to prevent abuse of Snowflake proxies. If a client could cause a
Snowflake proxy to make a WebSocket connection to any IP address, then
people would misuse Snowflake proxies to attack third-party WebSocket
applications. People who volunteer to run Snowflake proxies need to know
that their connection will be used for Tor-related circumvention, and
only that. If we added the ability for the Snowflake client to choose
its destination, the Snowflake proxy would still have to enforce a
whitelist or something, and permit connections only to known Snowflake
bridges. This kind of design is not impossible, but it would take
additional maintenance, and so far the benefits have not been perceived
to be worth the costs. There's some discussion on running multiple
Snowflake bridges here:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/28651

> Isn't this bad for the anonymity of Snowflake users since all users are
> connecting through the same bridge?

Yes, maybe, but it's the same with all bridges, really. Arguably, when
you use a bridge, with or without a pluggable transport, your Tor client
should make four-hop circuits:
	bridge → guard → middle → exit
But as it is, when you use a bridge, the bridge takes the place of your
guard:
	bridge → middle → exit
References:
https://support.torproject.org/glossary/#guard
	guard: The first relay in the Tor circuit, unless using a
	bridge. When using a bridge, the bridge takes the place of the
	guard.
https://research.torproject.org/techreports/ten-ways-discover-tor-bridges-2011-10-31.pdf#page=2
	Normal clients use guard nodes for the first hop of their
	circuits to protect them from long-term profiling attacks; but
	we chose to have bridge users use their bridge as a replacement
	for the guard hop, so we don't force them onto four-hop paths
	which would be less fun to use.

> Shouldn't Tor browser circuit display inform users that their connection
> actually goes through 4 hops (This Browser--->Snowflake proxy--->Bridge
> (flakey)--->Switzerland---->Germany---->Example.com) instead of three hops
> (This Browser--->Bridge (Snowflake)--->Germany--->Switzerland--->Example.com)?

The Snowflake proxy hop doesn't count as an onion routing hop. It
doesn't do any decryption/encryption and doesn't have an identity key.
Conceptually, it's no different from a network router, transporting
bytes from a source to a destination without modifying them. When you
use Tor without a bridge, your connection also goes through many routers
on the way to the guard, but those don't count as "hops" in the overlay
Tor circuit. Or if you configure a standard network proxy, the proxy
doesn't show up in the circuit display.
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk