[tor-dev] Summary of meek's costs, April 2015

Wed May 6 04:36:48 UTC 2015

Mike Perry transcribed 5.1K bytes:
> […]
>
> 2. 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

-- 
 ♥Ⓐ isis agora lovecruft
_________________________________________________________
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://blog.patternsinthevoid.net/isis.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1154 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150506/109e0ec1/attachment.sig>