Re: [tor-dev] Feature Request: please consider ship default Tor bridges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 David Fifield: > On Thu, Aug 17, 2017 at 05:19:44PM +, iry wrote: >> 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 >> following reply by Peter: >> >>> 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 ol=time=id=summary=keywords=status=1=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 mat=rss=id=summary=keywords=status=time=1 =time >> 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. > > 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. 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). > 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 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJZlfU8AAoJEKFLTbxtzdU8OOoQAIv+tJcNTi6hUExD2H/e8Wh6 YICR3OwSIp6v1kYD6aXWW+sL5OQzBe4K8pJsSD6IQzukfswytGd4BuTqYj2oiZSz kBKWas9CdHF2nC3MThCL65ImSzPgg+z1hOsy1f7ur0yFh0tj7yCKaXQFQqCMOO5+ lGxMYJfjF22zIHg9j3Q/IgrMNojBOLKtFD9KLNOURA1WMJGnVzrTx4lEyw9WaKBI A/eK1ZZWpRIiEYVyvvItU+/a54ax1Pirt2G4bZVKMnmiZ4evhjU8MuTOFPYRq/YI bUe6G4YJvNgqVxj0RmSTxaJHfX2KHOUEZQMR4uhmWMVTch0093rQBk1ICJy89tyz PWZmOzyp2H8QVSPxFPR5+5xzeinLDR5FsUc3Q9XeD1MiIlSk5W+EKGfQzVHpawGq lfo8kBN+iExTx4KErJPLreqv3iol9XUQgN/kD4SjDaHlM/YXt34NpOHfdafFdqDj yAwvAeGL5gSwDiV//Mie7fB493dcssaR70kl02hM51LuNywf0mzt0iYA9pyCv9Zo vzDskzAYElIKoWQBIkt15R22uC0bG6VW/BaeHS2SXRqIDLEsaq/f46E+D/IP+8o5 kMU/M3JygjvtyM+iKbnEOvxRBVfCLL0c0rO57TOdGd5Ijmrlqcpf+jQf4oZrsA0L nAlzDy2Y0GYB7eAHyx+b =9G6w -END PGP SIGNATURE- 0x6DCDD53C.asc Description: application/pgp-keys 0x6DCDD53C.asc.sig Description: PGP signature ___ tor-dev mailing list
Re: [tor-dev] Feature Request: please consider ship default Tor bridges
On Thu, Aug 17, 2017 at 05:19:44PM +, iry wrote: > 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 > following reply by Peter: > > > 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=time=id=summary=keywords=status=1=time > 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. 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. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Feature Request: please consider ship default Tor bridges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 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 following reply by Peter: > 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 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJZldAaAAoJEKFLTbxtzdU8QHEP/0DyAtD95JOKEkDulsyuuVfx uYT+5WGaRSFntqRq91RcNkHLHDy61JtLXhr5VIcz/tYIIe3TVZhI9idqbPgJMZc+ xxS/4r5qhkkcJ5X99xo7Jerz/0Y/4CKboREAkSstz15RL3FNLF6mwFZgWsiZ4rMa SkruE8qchz1KIUuWKZyx3HioloZgIHQkvqQ6fE4asGIs8gnaKeofpSwRGq85/Vcq T8D0WTqCFweLFaYzCWMtO7bVKXrfqC8rGLesLPJhxZbl0MJ3H/5TdvbPHn6VwRH0 AZCT5q7A+0fC/+HHwsn9SFhMo0TaIOtZBonOH58X3OEamKrmJOwqESvCPqILtMC3 pU2PtoOSDQEd684b2hxoR+0uRMOew+CJ+U7lzyh7yYU9x3jv//9CsFGcKcD+FoFG zrkDPJ75uzYGJjHZUFpnk8opwVy49TghYiVvjwm9/PXXQVvEiCGNEt7W1wTHX3Ja DygMsGN8GXg6AqWRESg4NcI8N/4U2EUEt+Li45u0qsTJ/uYmfamsC/WoacfjznaD JQVKjJQlhuk7F3qUPuxtxaGCLopLJd/uAUyYaI/HPrFeR3uIawSzCW9prTkk/E7n wAop3mErdp6JYnTacUb4pcYINIQf1c7FymbngrAmJzljxH4apZpBPugitAYvtJ2X 2OBJpUV0CtEJH3poicdq =oct9 -END PGP SIGNATURE- 0x6DCDD53C.asc Description: application/pgp-keys 0x6DCDD53C.asc.sig Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
