[tor-project] Re: Snowflake relays

[David Fifield via tor-project <tor-project@xxxxxxxxxxxxxxxxxxxx>]

On Fri, Apr 24, 2026 at 02:32:30PM +0200, Q Misell via tor-project wrote:
> At least in most situations, I would have no need for the whole WebRTC
> infrastructure of Snowflake, as the browser is not *usually* restricted from
> making a WebSocket connection. So, naturally I looked at the Snowflake source
> code to see how one would implement that, to discover some things I'm a little
> confused by. Firstly, the Tor node that the broker hands out seems to be a)
> hard coded and b) just the one (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/broker/broker.go#L75).
> Secondly, the number of active relays offering WebSocket
> connections are a grand total of 4 (https://metrics.torproject.org/rs.html#search/transport:snowflake?fields=transports).
> 
> Therefore, my question to those more knowledgeable is: why is this situation
> considered acceptable? Why is such relay centralisation fine? Is it even fine?

What is your specific concern with relay centralization?

If you mean that the anti-censorship and anonymity purposes of Tor
interact in ways that are not completely understood and may be in
conflict, you are right. Users who use bridges and pluggable transports
(for the purpose of anti-blocking) bypass the usual guard process (where
is there for anonymity purposes).

The situation is not really special to Snowflake, though. The default
obfs4 bridges handle (and similarly centralize) an even larger share of
traffic.

You are slightly misinterpreting the source code. DefaultBridges in
broker.go is a default for when the client doesn't specify which bridge
it wants to use -- this is for backward compatibility with old clients
and from a time when only one backend bridge was supported.

The system is more general than it was before, and now there are two
production bridges, snowflake-01 and snowflake-02. The interface with
tor unfortunately imposes some awkward constraints on how bridges may be
identified and deployed. In short, the fact that the client, not the
Snowflake infrastructure, chooses which bridge to use for a given
connection, requires bridges to be relatively static. We write about it
in the Snowflake paper:

	https://www.bamsoftware.com/papers/snowflake/#p85
	Another difficulty, harder to work around, has to do with Tor
	bridge authentication. A Tor bridge is identified by a long-term
	identity public key. If, on connecting to a bridge, the client
	finds that the bridge’s identity is not the expected one, the
	client terminates the connection. The Tor client can configure
	at most one identity per bridge; there is nothing like a
	certificate, for example, to indicate that multiple identities
	should be considered equivalent. This constraint leaves two
	options: either all Snowflake bridges must share the same
	cryptographic identity; or else it must be the client that
	chooses the bridge (and therefore knows what bridge identity to
	expect). While it would be possible to synchronize Tor identity
	keys across bridges, we preferred to keep keys independent, so
	that the effect of a security compromise at a bridge would be
	limited to that bridge only.

Remember, the address diversity of Snowflake comes from the temporary
proxies, not the backend bridges. From the point of view of
anti-censorship (but not necessarily from that of anonymity) it's not a
problem if there's just one or a few backend bridges.
_______________________________________________
tor-project mailing list -- tor-project@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to tor-project-leave@xxxxxxxxxxxxxxxxxxxx