[tor-dev] Feature Request: please consider ship default Tor bridges

[iry]

Hello Tor people!

A set of Tor bridges are shipped with Tor browser bundle[0], helping
users in Tor-censored area to connection to the Tor network. Since
system Tor users may also face the censorship problem, shall we
ship some Tor bridges along with the tor package?

The request is firstly reported[0] to Debian BTS and I got the

If upstream starts shipping bridges with their Tor releases, that
would naturally result in the Tor package shipping bridges as
well.
I do not know whether that's a good idea or not, but I don't think
deviating from upstream would be particularly worthwhile.

The following is some related information which may help the future
discussion:

The possible formats to hold those bridges can be:
1. JSON which is also the way tor-connection-wizard used so far[1];
2. plain text which is the same formatt given by the BridgeDB[2] by Tor
Project;
3. "Bridge" + plain text which is ready to be appended to a torrc file
or to be one of the torrc files in /etc/torrc.d/ (or whatever torrc.d
path Debain decides to use)

The default bridge shipped with tor package should be exactly the same
bridges contained in bridge_prefs.js[0] shipped with the latest stable
TBB. This is because:
1. The servers hosting default bridges are set up for huge amount of
traffic;
2. The servers hosting default bridges are probably audited by TPO for
better security;
3. Using a different set of bridges will distinguish the
anon-connection-wizard bridge users from the TBB bridge users, which
compromises their anonymity.

What do you think?

Looking forward to hearing your insights!

Best,
iry

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872456
[1]:
https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundl
e-Data/PTConfigs/bridge_prefs.js?h=7.5a3-linux
[2]:
https://github.com/irykoon/anon-connection-wizard/blob/master/usr/share/
anon-connection-wizard/bridges_default
[3]: https://bridges.torproject.org/options

Best,
iry

[David Fifield]

Post by iry
A set of Tor bridges are shipped with Tor browser bundle[0], helping
users in Tor-censored area to connection to the Tor network. Since
system Tor users may also face the censorship problem, shall we
ship some Tor bridges along with the tor package?
The request is firstly reported[0] to Debian BTS and I got the

If upstream starts shipping bridges with their Tor releases, that
would naturally result in the Tor package shipping bridges as
well.
I do not know whether that's a good idea or not, but I don't think
deviating from upstream would be particularly worthwhile.

To get an idea of how frequently the list of default bridges has
changed, see the tbb-bridges keyword in the bug tracker:
https://trac.torproject.org/projects/tor/query?keywords=~tbb-bridges&col=time&col=id&col=summary&col=keywords&col=status&desc=1&order=time

Post by iry
The default bridge shipped with tor package should be exactly the same
bridges contained in bridge_prefs.js[0] shipped with the latest stable
1. The servers hosting default bridges are set up for huge amount of
traffic;
2. The servers hosting default bridges are probably audited by TPO for
better security;
3. Using a different set of bridges will distinguish the
anon-connection-wizard bridge users from the TBB bridge users, which
compromises their anonymity.

There is an argument for using a different set of default bridges: when
one of the Tor Browser ones gets blocked, it won't affect the Debian
ones. For example, for a while, Orbot had some additional bridges that
Tor Browser did not have. When the firewall of China blocked the Tor
Browser bridges, the Orbot ones continued working for another nine
months (until they got blocked for a different reason). We know that at
least China and Kazakhstan pay attention to the default Tor Browser
bridges (and China blocks them as soon as they enter the source code,
even before a release).

So having a few bridges that are not shared with Tor Browser has that
advantage, at least. Of course, it's basically security by obscurity,
because a censor that can discover the Tor Browser bridges can (in
theory) also discover some other static list of bridges. But in practice
it will take censors time to build automation to read from a new list,
default bridges are security by obscurity anyway, though surprisingly
effective for that.

[iry]

Post by David Fifield

Post by iry
A set of Tor bridges are shipped with Tor browser bundle[0],
helping users in Tor-censored area to connection to the Tor
network. Since system Tor users may also face the censorship
problem, shall we ship some Tor bridges along with the tor
package?
The request is firstly reported[0] to Debian BTS and I got the

If upstream starts shipping bridges with their Tor releases,
that would naturally result in the Tor package shipping
bridges as well.
I do not know whether that's a good idea or not, but I don't
think deviating from upstream would be particularly
worthwhile.

To get an idea of how frequently the list of default bridges has
https://trac.torproject.org/projects/tor/query?keywords=~tbb-bridges&c

ol=time&col=id&col=summary&col=keywords&col=status&desc=1&order=time
Thank you very much for informing us the way to check default bridges'
update frequency.

The frequency is generally once per month while sometime three times a
month.

This RSS feed may be helpful to immediately inform us the new changes:

https://trac.torproject.org/projects/tor/query?keywords=~tbb-bridges&for
mat=rss&col=id&col=summary&col=keywords&col=status&col=time&desc=1&order
=time

Post by David Fifield

Post by iry
The default bridge shipped with tor package should be exactly
the same bridges contained in bridge_prefs.js[0] shipped with
the latest stable TBB. This is because: 1. The servers hosting
default bridges are set up for huge amount of traffic; 2. The
servers hosting default bridges are probably audited by TPO for
better security; 3. Using a different set of bridges will
distinguish the anon-connection-wizard bridge users from the TBB
bridge users, which compromises their anonymity.

when one of the Tor Browser ones gets blocked, it won't affect the
Debian ones. For example, for a while, Orbot had some additional
bridges that Tor Browser did not have. When the firewall of China
blocked the Tor Browser bridges, the Orbot ones continued working
for another nine months (until they got blocked for a different
reason). We know that at least China and Kazakhstan pay attention
to the default Tor Browser bridges (and China blocks them as soon
as they enter the source code, even before a release).
So having a few bridges that are not shared with Tor Browser has
that advantage, at least.

Thank you for offering me the interesting information. I did not
realize this advantage before.

The advantages 1 and 2 which I mentioned above will still be valid as
long as the bridges are TPO proved. Therefore, it sounds to be a good
idea to have some unique bridges shipped with Debian Tor (if including
Tor bridges is a good idea).

Post by David Fifield
Of course, it's basically security by obscurity, because a censor
that can discover the Tor Browser bridges can (in theory) also
discover some other static list of bridges. But in practice it
will take censors time to build automation to read from a new list,
default bridges are security by obscurity anyway, though
surprisingly effective for that.

That is true. Using security by obscurity strategy in censorship
circumvention is more like a resource competition. When the adversary
is a country like China, we may not be confident to win in long term.

Btw, Collateral Freedom seems to be one of the most effective ways to
circumvent Internet censorship in China. Circumvention tools that
depend on Collateral Freedom usually works fine, including meek,
lantern, psiphon3 etc. Therefore, I see a lot of potential work which
may benefit the Internet freedom in China. For example:
1. package meek into Debian
2. host (part of the) BridgeDB mirror on Github or AWS
3. #22402: https://trac.torproject.org/projects/tor/ticket/22402

[Roger Dingledine]

Post by iry
Btw, Collateral Freedom seems to be one of the most effective ways to
circumvent Internet censorship in China. Circumvention tools that
depend on Collateral Freedom usually works fine, including meek,
lantern, psiphon3 etc. Therefore, I see a lot of potential work which
1. package meek into Debian
2. host (part of the) BridgeDB mirror on Github or AWS
3. #22402: https://trac.torproject.org/projects/tor/ticket/22402

Some hopefully useful thoughts along these lines:

A) Most places around the world that need bridges these days need
pluggable transport bridges, not just vanilla bridges. So if we want to
bundle bridge addresses, we should bundle PT bridge addresses.

B) ...and that means we need to make sure that those PTs are well packaged
in Debian too, since the Tor deb by itself would not be able to use them.

C) I wonder if we could use the new %include torrc directive in this
situation:
https://bugs.torproject.org/1922
That is, when you apt-get install obfs4proxy, is that the right time to
populate /etc/torrc.d/obfs4-bridges with some (probably commented out
to start) lines that let you use those bridges if you want?

--Roger