Hi David, Arlo, Here's a thread on snowflake from tor-relays:
> On 24 Aug 2018, at 09:00, Mirimir <[email protected]> wrote: > >> On 08/22/2018 08:03 PM, teor wrote: >> >>>> On 23 Aug 2018, at 11:22, Mirimir <[email protected]> wrote: >>>> >>>>> On 08/22/2018 05:41 PM, teor wrote: >>>>> >>>>> On 23 Aug 2018, at 10:16, Mirimir <[email protected]> wrote: >>>>> >>>>> On 08/22/2018 04:17 PM, teor wrote: >>>>>> >>>>>> I don’t know about the current deployment plan for Snowflake, but I >>>>>> can point you to the relevant parts of the git repository: >>>>>> >>>>>>> On 22 Aug 2018, at 07:58, Nathaniel Suchy <[email protected]> wrote: >>>>>>> >>>>>>> Tor Browser 8 Alpha includes the Snowflake PT as it comes near a final >>>>>>> release, the adoption and usage of the Snowflake PT will continue to >>>>>>> rise. I now have the following questions... >>>>>>> >>>>>>> 1) Will a command line tool like an obfs4proxy come out so those of us >>>>>>> with infrastructure can run high capacity snowflake bridges. >>>>>> >>>>>> Like Meek, Snowflake is a 3-component transport: >>>>>> >>>>>> User -> Proxy -> Bridge >> >> Ok, here's a list of all the connections that happen in Snowflake: >> >> 1. Proxy -> Website to download the Proxy JS >> 2. Proxy -> Broker to register with the Broker >> 3. Client -> Broker to get a list of Proxies >> 3. Client -> Proxy -> Bridge to transmit data > > Thanks. So #3 is the WebRTC connection. Obviously not through Tor, or > any other proxy. > >>>>> I've read some of the Snowflake documentation. But I've found it >>>>> confusing. >>>> >>>> The FAQ explains the different components: >>>> https://github.com/keroserene/snowflake#faq >>> >>> Thanks. This in particular was helpful: >>> >>> | 1. Volunteers visit websites which host the "snowflake" proxy. >>> | (just like flashproxy) >>> >>> I don't recall seeing such a clear statement in other docs. >>> >>>>> I vaguely recall that Snowflake came up in a recent Tor >>>>> browser install. >>>> >>>> Yes, the *Snowflake client* is in the new Tor Browser alpha. >>>> >>>>> And I vaguely recall that there was an option to act as >>>>> a Snowflake proxy, via WebRTC. Is that true? >>>> >>>> Yes, volunteers on non-censored connections can run the *Snowflake proxy*. >>> >>> Wait. From that quote, it's websites that are hosting the snowflake >>> proxy. So are "volunteers" running a snowflake script, which is hosted >>> on the proxy website? >> >> Yes >> >>>> (Running a proxy in Tor Browser is not possible, because Tor Browser >>>> disables WebRTC.) >>> >>> OK. Which is a good thing. Because it's an external IP leak. >>> >>>>> And if so, what IP address >>>>> would be exposed? Would it be the IP address of the device running Tor >>>>> browser? That would be rather iffy. Almost like inviting users to run >>>>> relays, no? But perhaps I'm just confused. >>>> >>>> The Snowflake client connects to the Snowflake proxy. >>>> >>>> Snowflake uses the STUN WebRTC method, so clients and proxies discover >>>> each others’ external IP addresses. >>> >>> The use of "clients and proxies" is confusing here. The proxy is hosted >>> on some website, so having its external IP address exposed isn't at all >>> problematic. But what I suspect is that it's clients and _volunteers_ >>> that discover each others’ external IP addresses. So basically, the >>> snowflake script is circumventing the WebRTC block in Tor browser. >> >> The Snowflake Client is a separate executable with its own WebRTC >> stack. It performs a restricted set of network operations. It is >> launched by Tor, which is launched by Tor Browser. >> >> Tor Browser blocks WebRTC so that hostile websites can't run >> JavaScript that makes arbitrary connections outside Tor, >> revealing the user's IP address and other identifying data to an >> adversary. >> >> They're very different scenarios. >> >>>> If Snowflake used the TURN method, then the TURN server would discover >>>> both addresses: >>>> https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/client/rendezvous.go#n141 >>> >>> Sure. But the problem here, if I understand this correctly, is that >>> volunteers are sharing their external IP addresses with snowflake >>> clients. Is that correct? >> >> I'm not sure which IP addresses you think should be secret: >> * the IP addresses of the Tor users running the snowflake client >> (the threat to these tor users is the same as any other tor user, >> see below) >> * the IP addresses of the non-tor browser users running the snowflake >> proxy (the threat to these non-tor users is similar to browsing other >> WebRTC websites) >> >>> And yes, I get that you say "volunteers on non-censored connections". >>> But "non-censored" doesn't mean non-monitored. >>> >>> There really needs to be a prominent warning about this. >> >> What should the warning say, and who is it for? > > The warning should say that, by volunteering as a snowflake proxy, > you're exposing your public IP address to adversaries posing as > snowflake clients. > >>> Many people use >>> Tor for privacy and ~anonymity, not just for circumventing censorship. >> >> Tor keeps user IP addresses separate from the sites they're accessing. In >> particular, the exit and the remote site never learn user IP addresses. >> >> But Tor does reveal user IP addresses to the entry points into the network, >> which can be guards, bridges, or the entry point(s) for pluggable transports. >> >> Anyone can run a guard or a bridge or a snowflake proxy. >> >> How does the snowflake proxy create a different threat model? > > Sure, anyone can run guard and bridges, and log IPs of Tor users. But > they're both basically just relays. And, except for non-published > bridges, I gather that there are mechanisms for detecting malicious > behavior. Such as large blocks of related IPs. > > But what about snowflake clients? What's to stop adversaries from using > swarms of snowflake clients to enumerate users offering WebTRC links as > snowflake proxies? Will the Broker block suspicious snowflake clients? > > I do think that this is a clever way to circumvent censorship, by making > it easy for volunteers to run snowflake proxies. However, it's arguably > a major change in risk model for mainstream Tor users. Who might not > think through the implications of volunteering as snowflake proxies. > > It's far less risky than running relays, of course, in that the Tor > Project won't publish their IP addresses, and only snowflake clients and > bridges will see their IP addresses. So they won't get abuse complaints, > and their IPs won't likely get blacklisted. > > Still, their IPs might more readily be enumerated. And repressive > governments might go after them. Thanks for this feedback. I've cc'd the recent snowflake committers so they can respond. For future feedback on pluggable transport design and documentation, please use [email protected]. T _______________________________________________ tor-relays mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
