Hi everyone,
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. 2) Is the goal to replace OBFS4 with Snowflake or will they continue to co-exist? 3) How does Snowflake attempt to obfuscate, if at all it's traffic? How strong is the cryptography compared to obfs4proxy
Looking forward to learning more about this :)
Cordially, Nathaniel Suchy
Hi,
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 me@lunorian.is 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...
- 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
The command-line Snowflake Proxy is here:
https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/proxy-...
It will automatically be distributed to users using the same broker.
I am not sure if the default broker is the broker used by TBB users. You should ask tbb-dev@lists.torproject.org , or copy the configuration from the snowflake Proxy website.
The Snowflake Bridge pluggable transport is here: https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/server
However, your bridge needs to be distributed to users: * if you want to run a private bridge, just tell those users yourself * there is no automatic distribution, because BridgeDB does not support snowflake: https://bridges.torproject.org/options * if you want to run a TBB bridge, write to: tbb-dev@lists.torproject.org
- Is the goal to replace OBFS4 with Snowflake or will they continue to co-exist?
I’m not sure that any decisions have been made yet.
But my understanding is that Meek won’t work soon, because many sites don’t support domain fronting.
So I think the goals are: * replace Meek with Snowflake * replace obfs4 with some better protocol
- How does Snowflake attempt to obfuscate, if at all it's traffic? How strong is the cryptography compared to obfs4proxy
Snowflake’s components use TLS for point-to-point connections.
Inside Snowflake, client to relay connections have all the standard tor encryption.
I don’t know what obfuscation Snowflake uses, but you could read the code or documentation, and let us know. (Or wait for someone else to respond.)
T
-- teor
Please reply @torproject.org New subkeys 1 July 2018 PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ----------------------------------------------------------------------
On 08/22/2018 04:17 PM, teor wrote:
Hi,
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 me@lunorian.is 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...
- 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
I've read some of the Snowflake documentation. But I've found it confusing. I vaguely recall that Snowflake came up in a recent Tor browser install. And I vaguely recall that there was an option to act as a Snowflake proxy, via WebRTC. Is that true? 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 command-line Snowflake Proxy is here:
https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/proxy-...
It will automatically be distributed to users using the same broker.
I am not sure if the default broker is the broker used by TBB users. You should ask tbb-dev@lists.torproject.org , or copy the configuration from the snowflake Proxy website.
The Snowflake Bridge pluggable transport is here: https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/server
However, your bridge needs to be distributed to users:
- if you want to run a private bridge, just tell those users yourself
- there is no automatic distribution, because BridgeDB does not support snowflake: https://bridges.torproject.org/options
- if you want to run a TBB bridge, write to: tbb-dev@lists.torproject.org
- Is the goal to replace OBFS4 with Snowflake or will they continue to co-exist?
I’m not sure that any decisions have been made yet.
But my understanding is that Meek won’t work soon, because many sites don’t support domain fronting.
So I think the goals are:
- replace Meek with Snowflake
- replace obfs4 with some better protocol
- How does Snowflake attempt to obfuscate, if at all it's traffic? How strong is the cryptography compared to obfs4proxy
Snowflake’s components use TLS for point-to-point connections.
Inside Snowflake, client to relay connections have all the standard tor encryption.
I don’t know what obfuscation Snowflake uses, but you could read the code or documentation, and let us know. (Or wait for someone else to respond.)
T
-- teor
Please reply @torproject.org New subkeys 1 July 2018 PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi,
On 23 Aug 2018, at 10:16, Mirimir mirimir@riseup.net wrote:
On 08/22/2018 04:17 PM, teor wrote:
Hi,
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 me@lunorian.is 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...
- 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
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
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*.
(Running a proxy in Tor Browser is not possible, because Tor Browser disables WebRTC.)
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.
If Snowflake used the TURN method, then the TURN server would discover both addresses: https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/client...
T
On 08/22/2018 05:41 PM, teor wrote:
Hi,
On 23 Aug 2018, at 10:16, Mirimir mirimir@riseup.net wrote:
On 08/22/2018 04:17 PM, teor wrote:
Hi,
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 me@lunorian.is 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...
- 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
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?
(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.
If Snowflake used the TURN method, then the TURN server would discover both addresses: https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/client...
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?
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. Many people use Tor for privacy and ~anonymity, not just for circumventing censorship.
On 23 Aug 2018, at 11:22, Mirimir mirimir@riseup.net wrote:
On 08/22/2018 05:41 PM, teor wrote:
On 23 Aug 2018, at 10:16, Mirimir mirimir@riseup.net 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 me@lunorian.is 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...
- 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
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...
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?
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?
T
On 08/22/2018 08:03 PM, teor wrote:
On 23 Aug 2018, at 11:22, Mirimir mirimir@riseup.net wrote:
On 08/22/2018 05:41 PM, teor wrote:
On 23 Aug 2018, at 10:16, Mirimir mirimir@riseup.net 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 me@lunorian.is 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...
- 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:
- Proxy -> Website to download the Proxy JS
- Proxy -> Broker to register with the Broker
- Client -> Broker to get a list of Proxies
- 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...
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.
Hi David, Arlo,
Here's a thread on snowflake from tor-relays:
On 24 Aug 2018, at 09:00, Mirimir mirimir@riseup.net wrote:
On 08/22/2018 08:03 PM, teor wrote:
On 23 Aug 2018, at 11:22, Mirimir mirimir@riseup.net wrote:
On 08/22/2018 05:41 PM, teor wrote:
On 23 Aug 2018, at 10:16, Mirimir mirimir@riseup.net 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 me@lunorian.is 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:
- Proxy -> Website to download the Proxy JS
- Proxy -> Broker to register with the Broker
- Client -> Broker to get a list of Proxies
- 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...
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 tor-dev@lists.torproject.org.
T
tor-relays@lists.torproject.org
-
Mirimir -
Nathaniel Suchy -
teor