Re: [tor-dev] .i2p address support in torsocks
Hi, as I have said on the tor-dev channel, if you guys want a unique IPv4 address on a virtual machine I still have both available for you good people. It simply takes a gentle prod in the ribs for me to enable it and you can use and abuse it in any way wish you need. Regards, Phill. On 2 November 2013 22:18, str4d wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 11/03/2013 06:58 AM, David Goulet wrote: > > Apparently, I failed to put the person in CC :). > > I subscribed to tor-dev after talking with you :) > > > On 02 Nov (13:47:56), David Goulet wrote: > >> On 02 Nov (19:25:42), Maxim Kammerer wrote: > >>> On Sat, Nov 2, 2013 at 5:58 PM, David Goulet > >>> wrote: > For now, it would only be .i2p address support (like .onion). > In torsocks, it's not that difficult to support both > addressing. > >>> > >>> Does I2P's SOCKS proxy work in a way that's similar to Tor? > >>> Other proxies in I2P are protocol-specific — e.g., ports > >>> /4445 for HTTP(S) and 6668 for IRC. I am quite sure that > >>> protocol-specific local I2P proxies like HTTP and IRC strip > >>> sensitive information, so providing the user with an easy > >>> access to .i2p services via SOCKS might be the wrong thing to > >>> do. The SOCKS information page [1] is rather scarce on details > >>> of what actually goes on inside the proxy, however. > >> > >> For now, it's simply detecting an .i2p address, opening a > >> connection to the i2p daemon and pushing the request there. The > >> person at i2p I talked to told me that it's quite straight > >> forward and no special SOCKS5 mangling would be needed. > > Specifically, the I2P tunnel runs a local SOCKS server socket that > handles the standard SOCKS4/4a and SOCKS5 protocols, and any data to > be sent to the .i2p address is forwarded to an I2P socket. The > standard (unfiltered) SOCKS client tunnel only forwards data between > the SOCKS and I2P sockets, this should be functionally similar to Tor. > We also have a variant that filters IRC traffic for anonymity (using > SOCKS to connect to I2P IRC networks is a common use case), but this > occurs during the forwarding step, the SOCKS server socket is unchanged. > > If a non-.i2p address is detected, the SOCKS server opens a SOCKS > client connection to a configured SOCKS outproxy. This is designed to > enable chaining to Tor, but it has some bugs that need fixing (this > not working reliably is why I looked into torsocks). The configured > SOCKS outproxy also needs to be listening inside I2P, which adds > latency. If torsocks supported separate SOCKS ports for each > configured .suffix, a user could run both I2P and Tor locally and use > them in parallel instead of in series. > > >> If there is some work to do on the protocol side like you > >> mention, I would imagine that the i2p daemon does it or else... > >> well there is a problem :). > > If there are problems with our SOCKS implementation, they can be fixed > (or implemented - I2P supports datagrams, but SOCKS UDP is not yet > implemented). For filtering, it is up to the user to decide if they > want to use a filtered SOCKSIRC tunnel or an unfiltered SOCKS tunnel, > but it should not affect torsocks usage. (I want to make it possible > for different filters to be written and used, but the user still needs > to be made aware of the potential dangers to anonymity of generically > SOCKSifying applications [1].) > > str4d > > >> > >> Putting someone from i2p in CC: > >> > >> Cheers! David > >> > >>> > >>> [1] http://www.i2p2.de/socks.html > >>> > >>> -- Maxim Kammerer Liberté Linux: http://dee.su/liberte > >>> ___ tor-dev mailing > >>> list tor-dev@lists.torproject.org > >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > > > > > >> ___ tor-dev mailing > >> list tor-dev@lists.torproject.org > >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.14 (GNU/Linux) > > iQEcBAEBCgAGBQJSdXoiAAoJENXeOJaUpGWyBBMH/0c39pn97sBZvBj7HaMJAde2 > ucn6Ug9vd41AmxNcOEhG65wpOrfB32sfnwI7DsRAYlOhjdxdquUl1yQHzTzs7NeG > VLwRNe7e7Zv7VRj9uRp6t5+0YQU6++RkzhX5Jtn7l5W+3XYq0c4lRpSpwawP4NHN > Zc9MveAU1tbsQqvhsFoYoJEsADpBj+97Xf0D05buUYMttjsmKv254HhGaLpuDCpv > gEY3nBDHlHZqRziwxV7WmWPIsetdkATnmkUqcoCIPbZzJh2j6W3rZmHUieGU9OPC > M3offV3ImZd/gSVcKW1rzDEEZh2mDcmg0XkwMbsEwc/LCn15y5jPk2yFlGpKKsE= > =u2QY > -END PGP SIGNATURE- > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > -- https://wiki.ubuntu.com/phillw ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] .i2p address support in torsocks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/03/2013 06:58 AM, David Goulet wrote: > Apparently, I failed to put the person in CC :). I subscribed to tor-dev after talking with you :) > On 02 Nov (13:47:56), David Goulet wrote: >> On 02 Nov (19:25:42), Maxim Kammerer wrote: >>> On Sat, Nov 2, 2013 at 5:58 PM, David Goulet >>> wrote: For now, it would only be .i2p address support (like .onion). In torsocks, it's not that difficult to support both addressing. >>> >>> Does I2P's SOCKS proxy work in a way that's similar to Tor? >>> Other proxies in I2P are protocol-specific — e.g., ports >>> /4445 for HTTP(S) and 6668 for IRC. I am quite sure that >>> protocol-specific local I2P proxies like HTTP and IRC strip >>> sensitive information, so providing the user with an easy >>> access to .i2p services via SOCKS might be the wrong thing to >>> do. The SOCKS information page [1] is rather scarce on details >>> of what actually goes on inside the proxy, however. >> >> For now, it's simply detecting an .i2p address, opening a >> connection to the i2p daemon and pushing the request there. The >> person at i2p I talked to told me that it's quite straight >> forward and no special SOCKS5 mangling would be needed. Specifically, the I2P tunnel runs a local SOCKS server socket that handles the standard SOCKS4/4a and SOCKS5 protocols, and any data to be sent to the .i2p address is forwarded to an I2P socket. The standard (unfiltered) SOCKS client tunnel only forwards data between the SOCKS and I2P sockets, this should be functionally similar to Tor. We also have a variant that filters IRC traffic for anonymity (using SOCKS to connect to I2P IRC networks is a common use case), but this occurs during the forwarding step, the SOCKS server socket is unchanged. If a non-.i2p address is detected, the SOCKS server opens a SOCKS client connection to a configured SOCKS outproxy. This is designed to enable chaining to Tor, but it has some bugs that need fixing (this not working reliably is why I looked into torsocks). The configured SOCKS outproxy also needs to be listening inside I2P, which adds latency. If torsocks supported separate SOCKS ports for each configured .suffix, a user could run both I2P and Tor locally and use them in parallel instead of in series. >> If there is some work to do on the protocol side like you >> mention, I would imagine that the i2p daemon does it or else... >> well there is a problem :). If there are problems with our SOCKS implementation, they can be fixed (or implemented - I2P supports datagrams, but SOCKS UDP is not yet implemented). For filtering, it is up to the user to decide if they want to use a filtered SOCKSIRC tunnel or an unfiltered SOCKS tunnel, but it should not affect torsocks usage. (I want to make it possible for different filters to be written and used, but the user still needs to be made aware of the potential dangers to anonymity of generically SOCKSifying applications [1].) str4d >> >> Putting someone from i2p in CC: >> >> Cheers! David >> >>> >>> [1] http://www.i2p2.de/socks.html >>> >>> -- Maxim Kammerer Liberté Linux: http://dee.su/liberte >>> ___ tor-dev mailing >>> list tor-dev@lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > >> ___ tor-dev mailing >> list tor-dev@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBCgAGBQJSdXoiAAoJENXeOJaUpGWyBBMH/0c39pn97sBZvBj7HaMJAde2 ucn6Ug9vd41AmxNcOEhG65wpOrfB32sfnwI7DsRAYlOhjdxdquUl1yQHzTzs7NeG VLwRNe7e7Zv7VRj9uRp6t5+0YQU6++RkzhX5Jtn7l5W+3XYq0c4lRpSpwawP4NHN Zc9MveAU1tbsQqvhsFoYoJEsADpBj+97Xf0D05buUYMttjsmKv254HhGaLpuDCpv gEY3nBDHlHZqRziwxV7WmWPIsetdkATnmkUqcoCIPbZzJh2j6W3rZmHUieGU9OPC M3offV3ImZd/gSVcKW1rzDEEZh2mDcmg0XkwMbsEwc/LCn15y5jPk2yFlGpKKsE= =u2QY -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] .i2p address support in torsocks
I think i2p support makes sense. The only tricky part is what prereqs that reuuires. For an individual building torsocks, they'll either have or not have tor and have or not have i2p, and they can be detected, and that's fine. For a packaging system, the package has to have dependencies chosen, and this leaves the packager choosing wither to leave something out or inflict the dependency on everyone. If torsocks doesn't need tor installed, because it just uses socks5, and similarly for i2p, then there's no issue - this sounds good. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] .i2p address support in torsocks
Apparently, I failed to put the person in CC :). On 02 Nov (13:47:56), David Goulet wrote: > On 02 Nov (19:25:42), Maxim Kammerer wrote: > > On Sat, Nov 2, 2013 at 5:58 PM, David Goulet wrote: > > > For now, it would only be .i2p address support (like .onion). In > > > torsocks, it's not that difficult to support both addressing. > > > > Does I2P's SOCKS proxy work in a way that's similar to Tor? Other > > proxies in I2P are protocol-specific — e.g., ports /4445 for > > HTTP(S) and 6668 for IRC. I am quite sure that protocol-specific local > > I2P proxies like HTTP and IRC strip sensitive information, so > > providing the user with an easy access to .i2p services via SOCKS > > might be the wrong thing to do. The SOCKS information page [1] is > > rather scarce on details of what actually goes on inside the proxy, > > however. > > For now, it's simply detecting an .i2p address, opening a connection to > the i2p daemon and pushing the request there. The person at i2p I talked > to told me that it's quite straight forward and no special SOCKS5 > mangling would be needed. > > If there is some work to do on the protocol side like you mention, I > would imagine that the i2p daemon does it or else... well there is a > problem :). > > Putting someone from i2p in CC: > > Cheers! > David > > > > > [1] http://www.i2p2.de/socks.html > > > > -- > > Maxim Kammerer > > Liberté Linux: http://dee.su/liberte > > ___ > > tor-dev mailing list > > tor-dev@lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] .i2p address support in torsocks
On 02 Nov (19:25:42), Maxim Kammerer wrote: > On Sat, Nov 2, 2013 at 5:58 PM, David Goulet wrote: > > For now, it would only be .i2p address support (like .onion). In > > torsocks, it's not that difficult to support both addressing. > > Does I2P's SOCKS proxy work in a way that's similar to Tor? Other > proxies in I2P are protocol-specific — e.g., ports /4445 for > HTTP(S) and 6668 for IRC. I am quite sure that protocol-specific local > I2P proxies like HTTP and IRC strip sensitive information, so > providing the user with an easy access to .i2p services via SOCKS > might be the wrong thing to do. The SOCKS information page [1] is > rather scarce on details of what actually goes on inside the proxy, > however. For now, it's simply detecting an .i2p address, opening a connection to the i2p daemon and pushing the request there. The person at i2p I talked to told me that it's quite straight forward and no special SOCKS5 mangling would be needed. If there is some work to do on the protocol side like you mention, I would imagine that the i2p daemon does it or else... well there is a problem :). Putting someone from i2p in CC: Cheers! David > > [1] http://www.i2p2.de/socks.html > > -- > Maxim Kammerer > Liberté Linux: http://dee.su/liberte > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] .i2p address support in torsocks
On 02 Nov (16:13:37), adrelanos wrote: > Hi David, > > adding .i2p support to torsocks is perfectly fine. It's a feature, not a > limitation. Who doesn't want to use it won't be annoyed by it. (Other > than man page and --help entry, but well, life is tough. :) > > Someone else already said on this list some time ago "since torsocks is > agnostic about a Tor or a random socks server, there is no point in > calling it torsocks". If it works fine with normal socks servers and you > are willing to support that, sure, why not rename it. That is not entirely true. The rewrite effort made it actually *more* Tor aware. Furthermore, there is some Tor specific SOCKS extension for DNS resolution (that might actually be the norm elsewhere...) but for now seems not that agnostic. So the goal of torsocks right now is *not* to be agnostic about Tor where for instance .onion support is quite tor-ish. But it does not mean we should not think of a better name *especially* in terms of usability where for most users "socks" does not mean anything. I guess this is why "usewithtor" and "torify" wrappers were created. And that would make more sense if i2p address support comes in. David > > I am very happy that you are taking the lead fixing torsocks so I think > you also should also be the one who may make such decisions. > > Cheers, > adrelanos > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] .i2p address support in torsocks
On Sat, Nov 2, 2013 at 5:58 PM, David Goulet wrote: > For now, it would only be .i2p address support (like .onion). In > torsocks, it's not that difficult to support both addressing. Does I2P's SOCKS proxy work in a way that's similar to Tor? Other proxies in I2P are protocol-specific — e.g., ports /4445 for HTTP(S) and 6668 for IRC. I am quite sure that protocol-specific local I2P proxies like HTTP and IRC strip sensitive information, so providing the user with an easy access to .i2p services via SOCKS might be the wrong thing to do. The SOCKS information page [1] is rather scarce on details of what actually goes on inside the proxy, however. [1] http://www.i2p2.de/socks.html -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] .i2p address support in torsocks
Hi, David Goulet wrote (02 Nov 2013 15:58:52 GMT) : > For now, it would only be .i2p address support (like .onion). In > torsocks, it's not that difficult to support both addressing. I guess that people who use both I2P and Tor within Tails would be very happy with this. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] .i2p address support in torsocks
Il 11/2/13 5:13 PM, adrelanos ha scritto: > Hi David, > > adding .i2p support to torsocks is perfectly fine. It's a feature, not a > limitation. Who doesn't want to use it won't be annoyed by it. (Other > than man page and --help entry, but well, life is tough. :) I'd love also if someone pickup I2P integration for Tor2web: https://github.com/globaleaks/Tor2web-3.0/issues/82 -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] .i2p address support in torsocks
Hi David, adding .i2p support to torsocks is perfectly fine. It's a feature, not a limitation. Who doesn't want to use it won't be annoyed by it. (Other than man page and --help entry, but well, life is tough. :) Someone else already said on this list some time ago "since torsocks is agnostic about a Tor or a random socks server, there is no point in calling it torsocks". If it works fine with normal socks servers and you are willing to support that, sure, why not rename it. I am very happy that you are taking the lead fixing torsocks so I think you also should also be the one who may make such decisions. Cheers, adrelanos ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] .i2p address support in torsocks
Greetings everyone! I've been approached by I2P folks for adding ".i2p" address support in Torsocks. Since what torsocks does can be applied for both Tor and I2P, they felt that duplicating was not a good idea thus asking if merging both systems make sense and is possible. For now, it would only be .i2p address support (like .onion). In torsocks, it's not that difficult to support both addressing. I'm all for it, I don't see why it should not be done so I'm asking the community what do you think about that :). I can already see a question coming after this email being "Well there is "Tor" in torsocks". I'll keep that for an other thread because the whole naming of torsocks is on my todo list of things to discuss but before that I prefer getting the rewrite accepted. Thus, the naming is an "issue" but I want to address it later on (not only because of i2p). Cheers! David signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] two new proposals for bridgedb
I separated out the backend database improvements to BridgeDB from the social bridge distributor proposal. The former is finished and up for review and is being submitted to potential funders; the latter is still a draft (though now that some parts of the underlying crypto scheme and the threat model are detailed, early review is always helpful if anyone is super eager to point fingers at any mistakes I've made). Copies of both proposals are attached, and are also available in the common BridgeDB repo at https://gitweb.torproject.org/bridgedb.git/blob/refs/heads/feature/7520-social-dist-design:/doc/proposals/XXX-bridgedb-database-improvements.txt and https://gitweb.torproject.org/bridgedb.git/blob/refs/heads/feature/7520-social-dist-design:/doc/proposals/XXX-bridgedb-social-distribution.txt -- ♥Ⓐ isis agora lovecruft _ GPG: 4096R/A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt # -*- coding: utf-8 ; mode: org -*- Filename: XXX-bridgedb-database-improvements.txt Title: "Scalability and Stability Improvements to BridgeDB: Switching to a Distributed Database System and RDBMS" Author: Isis Agora Lovecruft Created: 12 Oct 2013 Related Proposals: XXX-social-bridge-distribution.txt Status: Open * I. Overview BridgeDB is Tor's Bridge Distribution system, which currently has two major Bridge Distribution mechanisms: the HTTPS Distributor and an Email Distributor. [0] BridgeDB is written largely in Twisted Python, and uses Python2's builtin sqlite3 as its database backend. Unfortunately, this backend system is already showing strain through increased times for queries, and sqlite's memory usage is not up-to-par with modern, more efficient, NoSQL databases. In order to better facilitate the implementation of newer, more complex Bridge Distribution mechanisms, several improvements should be made to the underlying database system of BridgeDB. Additionally, I propose that a clear distinction in terms, as well as a modularisation of the codebase, be drawn between the mechanisms for Bridge Distribution versus the backend Bridge Database (BridgeDB) storage system. This proposal covers the design and implementation of a scalable NoSQL ― Document-Based and Key-Value Relational ― database backend for storing data on Tor Bridge relays, in an efficient manner that is ammenable to interfacing with the Twisted Python asynchronous networking code of current and future Bridge Distribution mechanisms. * II. Terminology BridgeDistributor := A program which decides when and how to hand out information on a Tor Bridge relay, and to whom. BridgeDB := The backend system of databases and object-relational mapping servers, which interfaces with the BridgeDistributor in order to hand out bridges to clients, and to obtain and process new, incoming ``@type bridge-server-descriptors``, ``@type bridge-networkstatus`` documents, and ``@type bridge-extrainfo`` descriptors. [3] BridgeFinder := A client-side program for an Onion Proxy (OP) which handles interfacing with a BridgeDistributor in order to obtain new Bridge relays for a client. A BridgeFinder also interfaces with a local Tor Controller (such as TorButton or ARM) to handle automatic, transparent Bridge configuration (no more copy+pasting into a torrc) without being given any additional privileges over the Tor process, [1] and relies on the Tor Controller to interface with the user for control input and displaying up-to-date information regarding available Bridges, Pluggable Transport methods, and potentially Invite Tickets and Credits (a cryptographic currency without fiat value which is generated automatically by clients whose Bridges remain largely uncensored, and is used to purchase new Bridges), should a Social Bridge Distributor be implemented. [2] * III. Databases ** III.A. Scalability Requirements Databases SHOULD be implemented in a manner which is ammenable to using a distributed storage system; this is necessary because many potential datatypes required by future BridgeDistributors MUST be stored permanently. For example, in the designs for the Social Bridge Distributor, the list of hash digests of spent Credits, and the list of hash digests of redeemed Invite Tickets MUST be stored forever to prevent either from being replayed ― or double-spent ― by a malicious user who wishes to block bridges faster. Designing the BridgeDB backend system such that additional nodes may be added in the future will allow the system
[tor-dev] two new proposals for bridgedb
I separated out the backend database improvements to BridgeDB from the social bridge distributor proposal. The former is finished and up for review and is being submitted to potential funders; the latter is still a draft (though now that some parts of the underlying crypto scheme and the threat model are detailed, early review is always helpful if anyone is super eager to point fingers at any mistakes I've made). Copies of both proposals are attached, and are also available in the common BridgeDB repo at https://gitweb.torproject.org/bridgedb.git/blob/refs/heads/feature/7520-social-dist-design:/doc/proposals/XXX-bridgedb-database-improvements.txt and https://gitweb.torproject.org/bridgedb.git/blob/refs/heads/feature/7520-social-dist-design:/doc/proposals/XXX-bridgedb-social-distribution.txt -- ♥Ⓐ isis agora lovecruft _ GPG: 4096R/A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt # -*- coding: utf-8 ; mode: org -*- Filename: XXX-social-bridge-distribution.txt Title: Social Bridge Distribution Author: Isis Agora Lovecruft Created: 18 July 2013 Related Proposals: 199-bridgefinder-integration.txt XXX-bridgedb-database-improvements.txt Status: Draft * I.Overview This proposal specifies a system for social distribution of the centrally-stored bridges within BridgeDB. It is primarily based upon Part IV of the rBridge paper, [1] utilising a coin-based incentivisation scheme to ensure that malicious users and/or censoring entities are deterred from blocking bridges, as well as socially-distributed invite tickets to prevent such malicious users and/or censoring entities from joining the pool of Tor clients who are able to receive distributed bridges. * II. Motivation & Problem Scope As it currently stands, Tor bridges which are stored within BridgeDB may be freely requested by any entity at nearly any time. While the openness, that is to say public accessibility, of any anonymity system certainly provisions its users with the protections of a more greatly diversified anonymity set, the damages to usability, and the efficacy of such an anonymity system for censorship circumvention, are devastatingly impacted due to the equal capabilities of both a censoring/malicious entity and an honest user to request new Tor bridges. Thus far, very little has been done to protect the volunteered bridges from eventually being blocked in various regions. This severely restricts the overall usability of Tor for clients within these regions, who, arguably, can be even more in need of the identity protections and free speech enablement which Tor can provide, given their political contexts. ** II.A. Current Tor bridge distribution mechanisms and known pitfalls: *** 1. HTTP(S) Distributor At https://bridges.torproject.org, users may request new bridges, provided that they are able to pass a CAPTCHA test. Requests through the HTTP(S) Distributor are not allowed to be made from any current Tor exit relay, and a hash of the user's actual IP address is used to place them within a hash ring so that only a subset of the bridges allotted to the HTTP(S) Distributor's pool may become known to a(n) adversary/user at that IP address. 1.a. Known attacks/pitfalls: 1) An adversary with a diverse and large IP address space can easily retrieve some significant portion of the bridges in the HTTPS Distributor pool. 2) The relatively low cost of employing humans to solve CAPTCHAs is not sufficient to deter adversaries with requisite economic resources from doing so to obtain bridges. [XXX cost of employment] *** 2. Email Distributor Clients may send email to brid...@bridges.torproject.org with the line "get bridges" in the body of the email to obtain new bridges. Such emails must be sent from a Gmail or Yahoo! account, which is required under the assumption that such accounts are non-trivial to obtain. 2.a. Known attacks/pitfalls: 1) Mechanisms for purchasing pre-registered Gmail accounts en masse exists, charging between USD$0.25 and USD$0.70 per account. With roughly 1000 bridges in the Email Distributor's pool, distributing 3 bridges per email response, * III. Terminology & Notations ** III.A. Terminology Definitions User := A client connecting to BridgeDB in order to obtain bridges. ** III.B. Notations |+-| | Symbol | Definition | |+-| | U | A user connecting to BridgeDB in order to obtain bridges, identified by a
