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
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.
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?
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
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 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.
