[tor-relays] snowflake vs bridges (vs node)

Hey,

I just saw, that it's possible to run snowflake[1] not only as browser plugin, but also standalone. So I am wondering what makes more sense, run a bridge with obsf4 or run a snowflake instance instead of a bridge. Or would it even make sense to install both on one server?

And generally, what's more needed atm: bridge, non-exit, exit or snowflake?

Thanks!

fran

[1] Home · Wiki · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab

···

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Hello there.

And generally, what's more needed atm: bridge, non-exit, exit or
snowflake?

I'm not an expert at all, but the most needed type of relay is exit
([1]) and I suppose always will be, as they are the most prone to raise
legal issues ([1]) and have the highest requirements ([2]). Also, to my
understanding, if there were many exit nodes but guard or middle were
missing, exit nodes would be used for the first two hops as well, so if
you have enough resources and you will to I'd say you should go with an
exit node.
As for the question about bridges I'm a newbie, so I'll leave the
answer to someone with some expertise :).

Eldalië

[1]

[2]

···

On Thu, 3 Feb 2022 18:14:49 +0100 Fran via tor-relays <tor-relays@lists.torproject.org> wrote:

Hey,

I just saw, that it's possible to run snowflake[1] not only as
browser plugin, but also standalone. So I am wondering what makes
more sense, run a bridge with obsf4 or run a snowflake instance
instead of a bridge. Or would it even make sense to install both on
one server?

And generally, what's more needed atm: bridge, non-exit, exit or
snowflake?

Thanks!

fran

[1]
Home · Wiki · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
tor-relays Info Page

--
Eldalië
My private key is attached. Please, use it and provide me yours!

(Attachment 7CE7571174A1961293D0CEF91EACF195B8F3D922.asc is missing)

1 Like

Hej Eldalië,

thanks for your answer.

Tor project runs campaigns for running more bridges [1-3] because there
was/is (?) a shortage and/or countries changed their censorship policy (e. g. Russia). So I'd say the statement in the FAQ is a little bit to simple. At different times a shortage of one or the other node might occur. :slight_smile:

I think the answer might also depend on what kind of servers you are able to run. E. g. a server in a cloud/with a hoster where you can spin instances up/down on a regular basis (weekly/monthly?) and change the IP in this process, might be good for bridges in case they got blocked by a censor (no idea on how long a usual bridge is usable before it gets blocked in parts of the world). If you are able to run the node for many years with the same IP addressing, maybe a non-bridge would be better, so the node might become a fallback-authority node one day.

If you don't use HiddenServiceSingleHopMode for you onion services, six tor nodes are in between the visitor and the server which results in a lot of bandwidth usage in the tor network. So some non-exits might also be handy in case onion service usage picks up.

If you take a look at Traffic – Tor Metrics it seems to me like there is much more advertised bandwidth than consumed bandwidth for all flags. So maybe more bridges is the answer?

But I really cannot tell because I don't have enough insights and so I just went with bridges (time to be blocked for a usual bridge would be really interesting to know if/when I should convert the bridges to regular nodes or change IP addressing).

Thanks and have a great weekend!

Fran

[1] Run Tor Bridges to Defend the Open Internet | The Tor Project
[2] Help Censored Users, Run a Tor Bridge | The Tor Project
[3] Wrapping up Run a Tor bridge campaign | The Tor Project

···

On 2/4/22 10:40, Eldalië via tor-relays wrote:

Hello there.

And generally, what's more needed atm: bridge, non-exit, exit or
snowflake?

I'm not an expert at all, but the most needed type of relay is exit
([1]) and I suppose always will be, as they are the most prone to raise
legal issues ([1]) and have the highest requirements ([2]). Also, to my
understanding, if there were many exit nodes but guard or middle were
missing, exit nodes would be used for the first two hops as well, so if
you have enough resources and you will to I'd say you should go with an
exit node.
As for the question about bridges I'm a newbie, so I'll leave the
answer to someone with some expertise :).

Eldalië

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Hello Fran,

Hey,

I just saw, that it's possible to run snowflake[1] not only as browser
plugin, but also standalone. So I am wondering what makes more sense, run a
bridge with obsf4 or run a snowflake instance instead of a bridge. Or would
it even make sense to install both on one server?

You should not run both on the same IP address. If a censor blocks your
obfs4 bridge IP, a user won't be able to connect using your snowflake
proxy.

For Snowflake, you can also find the standalone proxy instructions here:

And generally, what's more needed atm: bridge, non-exit, exit or snowflake?

All of the above :slight_smile:

But, if it's your first running a relay, I would recommend starting with
a non-exit: bridge/middle/guard.

Check out our setup guides and relay documentation:

cheers,
Gus

···

On Thu, Feb 03, 2022 at 06:14:49PM +0100, Fran via tor-relays wrote:

Thanks!

fran

[1] Home · Wiki · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
tor-relays Info Page

--
The Tor Project
Community Team Lead

Hey Gus,

thanks for your answer.

You should not run both on the same IP address. If a censor blocks your
obfs4 bridge IP, a user won't be able to connect using your snowflake
proxy.

Let me try to rephrase:

I don't know how bridges with obfs4 vs snowflake work in hiding that they provide access to the tor network (where is the difference?).
I assume that there is a difference, because if not, why bother with another approach. So providing these two different access methods would allow people to connect with any of the two methods. If the IP addresses would be blocked both wouldn't work anymore, but till then more options would be available.

If IP addresses wouldn't be limited giving both methods individual IP addresses would of course be better. I can do this easily for v6, even out of another /64 but for v4...well...

But would running bridge and snowflake on the same v4 do any "harm"? For example like bridges are easier to be detected and only running snowflake might result in a longer usability of the node.

Thanks a lot, have a great weekend!

Fran

···

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Tor project runs campaigns for running more bridges [1-3] because there
was/is (?) a shortage and/or countries changed their censorship policy
(e. g. Russia). So I'd say the statement in the FAQ is a little bit to
simple. At different times a shortage of one or the other node might
occur. :slight_smile:

Yeah, the number of Tor bridges has almost doubled in the last weeks.

I think the answer might also depend on what kind of servers you are
able to run.

That mainly depends on your monthly bandwidth. Under 10 TB/month -> run some
bridges. From 50 TB/month a guard,middle,exit relay is worthwhile.

If you don't use HiddenServiceSingleHopMode for you onion services, six
tor nodes are in between the visitor and the server which results in a
lot of bandwidth usage in the tor network. So some non-exits might also
be handy in case onion service usage picks up.

Exits are or do everything: guard, middle, exit, HSDir, Intro & rendezvous
point :wink:

Very good suggestion recently in this list¹:
Set up new relays/IPs as bridges first and then later change them to relays.

¹Mmm, I'm getting old. I think that was toralf or Felix.

···

On Friday, February 4, 2022 3:15:52 PM CET Fran via tor-relays wrote:

--
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

1 Like

Quoting Fran via tor-relays (2022-02-04 18:34:45)

I don't know how bridges with obfs4 vs snowflake work in hiding that they
provide access to the tor network (where is the difference?).
I assume that there is a difference, because if not, why bother with
another approach. So providing these two different access methods would
allow people to connect with any of the two methods. If the IP addresses
would be blocked both wouldn't work anymore, but till then more options
would be available.

If IP addresses wouldn't be limited giving both methods individual IP
addresses would of course be better. I can do this easily for v6, even
out of another /64 but for v4...well...

But would running bridge and snowflake on the same v4 do any "harm"? For
example like bridges are easier to be detected and only running
snowflake might result in a longer usability of the node.

Yes, there are many differencies. snowflake does make the traffic look like
webrtc (like a video conference) and obfs4 makes the traffic look like random
noise. Also the clients use different mechanisms to discover the relays.

If you run both in the same IP address and the censor has a way to discover one
but not the other both of them will be blocked at once. So you are making it
easier for the censor to discover them and block them. That is why we don't want
people to run both in the same IP address.

···

--
meskio | https://meskio.net/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
My contact info: https://meskio.net/crypto.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.

1 Like

Thanks meskio, this helped a lot to clarify things.

So I thought of trying to run a bride and a snowflakeproxy on one VM with individual IP addressing in v4 and v6 for each by adding secondary addresses to to the WAN interface. But after compiling the go binary I fail to find out how to tell snowflake which IP to bind to/use.

For the bridge this can be achieved with:

Address <IPv4>
Address <IPv6>
OutboundBindAddress <IPv4>
OutboundBindAddress <IPv6>

(and maybe to be save also set OutboundBindAddressPT, OutboundBindAddressExit and OutboundBindAddressOR)

But for snowflake I'm missing the options:

Usage of ./proxy:
   -broker string
       broker URL (default "https://snowflake-broker.torproject.net/&quot;\)
   -capacity uint
       maximum concurrent clients
   -keep-local-addresses
       keep local LAN address ICE candidates
   -log string
       log filename
   -nat-retest-interval duration
       the time interval in second before NAT type is retested, 0s disables retest. Valid time units are "s", "m", "h". (default 24h0m0s)
   -relay string
       websocket relay URL (default "wss://snowflake.bamsoftware.com/")
   -stun string
       broker URL (default "stun:stun.stunprotocol.org:3478")
   -summary-interval duration
       the time interval to output summary, 0s disables retest. Valid time units are "s", "m", "h". (default 1h0m0s)
   -unsafe-logging
       prevent logs from being scrubbed
   -verbose
       increase log verbosity

Could be solved with VRFs/namespaces but would involve bridging, veths...too snowflaky for me (same goes for containers).

So I guess I'll just keep the bridges and make then relays one day.

Thanks for all who helped!

best
fran

···

On 2/7/22 11:12, meskio wrote

Yes, there are many differencies. snowflake does make the traffic look like
webrtc (like a video conference) and obfs4 makes the traffic look like random
noise. Also the clients use different mechanisms to discover the relays.

If you run both in the same IP address and the censor has a way to discover one
but not the other both of them will be blocked at once. So you are making it
easier for the censor to discover them and block them. That is why we don't want
people to run both in the same IP address.

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Quoting Fran via tor-relays (2022-02-07 19:50:34)

So I thought of trying to run a bride and a snowflakeproxy on one VM with
individual IP addressing in v4 and v6 for each by adding secondary addresses
to to the WAN interface. But after compiling the go binary I fail to find out
how to tell snowflake which IP to bind to/use.

The snowflake proxy doesn't bind to any address, is a bit different. It acts as
a webrtc client, it initiates the connection to the broker to ask for snowflake
clients. That means that the visible IP address of the snowflake proxy will be
your default public address.

···

--
meskio | https://meskio.net/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
My contact info: https://meskio.net/crypto.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.