How about Snowflake works


Since a few days I read some documentation about Snowflake and especially how it works.

I read the Wiki here => Technical Overview · Wiki · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab but I’m not sure to understand the overview, even the first steps.

I mean, when the Tor user choose Snowflake as transport protocol, the browser will send a request but where and to who? According this shema => Snowflake ❄️ , the request is sent directly to the Broker then the Broker will choose a Snowflake proxy from another client (it should be from the browser extension or via a website with the “iframe” balise), the Broker send it back to the original client and both (client and Snowflake proxy) will establish a connection in peer-to-peer in WebRTC, then go to the Tor network.

In summary, is it correct? If yes, what is technically a Broker? Is it specific server somewhere, managed by volunteer? On the Wiki it tells “which is a server running on a third party web service” but I’m not sure to understand what does it mean

Thanks in advance for your help :slight_smile:

Broker helps client and proxy find each other.
Then data flows this way:
Tor client ↔ snowflake proxy ↔ snowflake bridge ↔ Tor network.

It’s a server at .

No, by Tor team.
Snowflake bridges are also run by Tor team.
Snowflake proxies and most of Tor network (relays) are run by volunteers.

1 Like

Thanks Vort for your answer.

I’ll have a look on this points, I didn’t know there was Snowflak proxies AND Snowflake bridges. With the shema at the Snowflake page I can understand now how it works.

Thanks :slight_smile:


I’m writing a documentation for myself about Snowflake and I’ve still a little doubt, at this time what is the goal of the Snowflake bridge, managed by Tor team?

The Snowflake proxies can’t forward trafic directly to a Tor guard relay? (maybe because they are not directly connected to the Tor network so they don’t know about guard relays?

Thanks :slight_smile:

I think bridges are needed because snowflake proxy is designed to work inside of a browser and browsers do not allow to make connections with protocols, used by Tor relays. So intermediate server is needed, which converts WebSocket protocol to Tor protocol.
Why not make Tor relays support WebSocket directly? I don’t know.

There is a second reason for having bridges after the proxy.
Proxies are assumed to be as ephemeral as snowflakes. And Tor doesn’t have a built-in session resumption mechanism.
Without the bridge, if someone is running a Snowflake proxy in their browser, and closes that browser, any people using that proxy at that time will lose their connection (aborting any download in progress or stuff like that). An important thing the Snowflake bridge does is implement a form of session resumption, so that if a Snowflake proxy goes down, the user only notice a blip while a connection get reestablished, what they do isn’t entirely aborted. Technically, it could also allow multipathing (use of multiple snowflake proxy at once) so you’d have presumably a higher available bandwidth, and wouldn’t even notice anything if one of the proxy disappeared, but afaik this isn’t implemented yet


Thanks Vort and Trinity.

With your explainations that true now I better understand why we call it a bridge, it makes sense ^^ . I think it’s more clear now, thanks :slight_smile:

There’s a few reasons for this, but security is a major one. It’s the same reason that we have an allow list for a fixed set of known Snowflake bridges that clients can connect to through Snowflake proxies. Allowing arbitrary connections directly from Snowflake proxies would allow the network to be used for DDoS attacks, and allowing connections to arbitrary Tor relays provides an upgrade path from WebSocket to plain TCP for all of these connections.

Why arbitrary?
Snowflake proxy can download consensus from authorities in a similar way relays do this.

What’s the problem for relays to have one more protocol supported?
Some users will use WebSocket wrapper, some users will use TCP (raw Tor protocol).
I can’t understand what upgrade path you are talking about.

I made an issue about this, It appears to be (at least close to) possible:

But yeah, you have to know the address of the bridge to connect to it, like it is now with the current two Snowflake bridges.

1 Like

@cecylia I think you edited your old post instead of making a new one to reply.

1 Like

I was talking about how snowflake proxies can find bridges (relays, which support WebSocket), not how they can become bridges.

Do you mean attacker can turn users of some large website into bots, who will DDoS relays?
If that will be not attackers, but users, who need such single-hop service, then I don’t think it’s a big problem.
But I agree, some risk exists.

Ah that’s what happened >.< thanks for pointing that out

Edit: I think I fixed it by reverting the old post and posting a new reply. It might’ve broken threading for the most recent reply but now the context is all there.

@trinity-1686a’s answer above is a great answer and maybe the most fundamental explanation of why Snowflake proxies shouldn’t be treated as bridges. I’ll add that doing so would also require an implementation of tor for the addon which isn’t feasible for this project, or what we want.

I can’t understand what upgrade path you are talking about.

Sorry, I dragged us a bit off topic with this because it has been brought up before as part of a discussion of Snowflake. By upgrade path, I mean that if all Tor relays functioned as Web Socket servers, and allowed incoming connections from any source, then that would allow malicious Javascript applications to use the set of all Tor exits as a single-hop means of turning more restrictive Web Socket connections into raw TCP connections to allow them to attack a wider range of hosts and protocols.

To be honest, this probably isn’t as big of a concern as the increased attack surface each relay would have by supporting another protocol. It isn’t a trivial decision to add server side support for entirely new protocol and something like this that would affect the entire Tor network sounds unnecessarily risky to me. Especially since there are other very good reasons for why Snowflake proxies could not be bridges anyway.


This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.