Mike Perry transcribed 5.1K bytes:
[…]
- Perhaps cleaner: if BridgeDB itself were accessible through a domain
front, we could export its captcha and bridge distribution through an API on this domain front. Once your IP forwarding in https://trac.torproject.org/projects/tor/ticket/13171 is solved, BridgeDB even could still make use of its IP-based hashring logic.
Maybe don't set the HTTP header name for the forwarded client IP to "X-Forwarded-For". Otherwise, it will probably get overridden by the Apache server which acts as a reverse proxy in front of BridgeDB's Twisted servers. Just set it to something else, e.g. "X-Domain-Fronted-For".
Then, on the BridgeDB side, it's easy: I'd need to add logic to BridgeDB to handle preferring "X-Domain-Fronted-For", "X-Forwarded-For", then request IP, in that order.
If we make use of this API in Tor Launcher (and we will, as soon as it exists — I'd even pull a crazy and roll it out in the middle of a stable, given the rapid rate of increase in these costs), users would not need to know the magic incantations to access this front, and new bridges could be obtained behind the scenes for them. All they would have to do is keep solving captchas until something worked (until we also implement some kind of fancy crypto like RBridge).
Perhaps the "BridgeDB API" part of what you want is the Tor Browser bridge distributor that I mentioned in §3.1, SOW.9., in my Statement of Work [0] for OTF?
Additionally, SOW.9. is actually the chronological precursor to SOW.10., the latter of which is implementing rBridge (or at least getting started on it). (Work on this is still waiting on OTF to officially grant me the fellowship, along with the other prerequisite tasks getting finished.)
But just to be clear — since it sounds like you've asked for several new things in that last paragraph :) — which do you want:
1. Tor Browser users use meek to get to BridgeDB, to get non-meek bridges by: 1.a. Retrieving and solving a CAPTCHA inside Tor Launcher. 1.b. Solving a CAPTCHA on a BridgeDB web page.
2. Tor Browser users use BridgeDB's domain front, to get non-meek bridges by: 2.a. Retrieving and solving a CAPTCHA inside Tor Launcher. 2.b. Solving a CAPTCHA on a BridgeDB web page.
If you want #2, then we're essentially transferring the domain-fronting costs (and the DDoS risks) from meek to BridgeDB, and we'd need to decide who is going to maintain that service, and who is going to pay for it. Could The Tor Project fund BridgeDB domain fronting?
As far as maintenance goes, the threat to any of our domain fronts, including meek and any BridgeDB domain fronts, from China's Great Cannon waging economic counter-counter-warfare by attacking us (like they did to GreatFire.org) is something which must be taken into account. Will the maintainer of this service need to wake up to emergency, the-request-rate-is-skyrocketing, emails at 4AM to shut the service down? Or do we already have technical measures to detect DDoS and prevent $30,000+/day CDN bills? Further, what happens when #2 is being DDoS-ed? Should we fallback to #1? Should we have both, and some strategy for balancing between the two?
Now that we have a browser updater, I think it is also OK for us to provide autoprobing options for Tor Launcher, so long as the user is informed what this means before they select it, and it only happens once.
Probing all of the different Pluggable Transport types simultaneously provides an excellent training classifier for DPI boxes to learn what new Pluggable Transport traffic looks like.
As long as it happens only once, and only uses the bridges bundled in Tor Browser, I don't see any issue with auto-selecting from the drop-down of transport methodnames in a predefined order. It's what users do anyway.
The autoprobing could then keep asking for non-meek bridges for either a given type of the user's choice, or optionally all non-meek types (with an additional warning that this increases their risk of being discovered as a Tor user).
If the autoprobing is going to include asking BridgeDB (multiple times?) for different types of bridges in the process, whether through a BridgeDB domain front or not, then I think there needs to be more discussion…
* Do you think could you explain more about the steps this autoprobing entails?
* Is the autoprobing meant to solve the issue of not knowing which transport will work? Or the problem of not knowing whether the bridges in Tor Browser are already blocked? Or some other problem?
* Does BridgeDB continue to always normally answer with one transport methodname at a time, unless the "russianroulette" meta-transport type is requested?
If we follow BridgeDB's spec, [1] and we allow wish for the logic controlling how Tor Browser users are handled to be separate (and thus more maintainable), then this will require a new bridge Distributor, and we should probably start thinking about the threat model/security requirements, and behaviours, of the new Distributor. Some design questions we'll need to answer include:
* Should all points on the Distributor's hashring be reachable at a given time (i.e., should there be some feasible way, at any given point in time, to receive any and every Bridge allocated to the Distributor)?
* Or should the Distributor's hashring rotate per time period? Or should it have sub-hashrings which rotate in and out of commission?
* Should it attempt to balance the distribution of clients to Bridges, so that a (few) Bridge(s) at a time aren't hit with tons of new clients?
* Should it treat users coming from the domain front as separate from those coming from elsewhere? (Is is even possible for clients to come from elsewhere? Can clients use Tor to reach this distributor? Can Tor Browser connect directly to BridgeDB, not through the domain front?)
* If we're going to do autoprobing, should it still give out a maximum of three Bridges per request? More? Less?
Would you and/or Isis be able to work on this on the backend? If not, can either of you recommend someone that might be able to help with the domain fronting bits and other bits involved?
I'm in. Yawning mentioned wanting to work on this too. :)
[0]: https://people.torproject.org/~isis/otf-etfp-sow.pdf#subsection.3.1 [1]: https://gitweb.torproject.org/torspec.git/tree/bridgedb-spec.txt