[tor-bugs] #1839 [BridgeDB]: Rotate available bridges over time

[Tor Bug Tracker & Wiki]

#1839: Rotate available bridges over time
-----------------------------+-------------------------------------------
     Reporter:  arma         |      Owner:  isis
         Type:  enhancement  |     Status:  needs_review
     Priority:  blocker      |  Milestone:
    Component:  BridgeDB     |    Version:
   Resolution:               |   Keywords:  bridgedb-dist, bridgedb-0.3.2
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+-------------------------------------------
Changes (by isis):

 * keywords:  easy, bridgedb-dist => bridgedb-dist, bridgedb-0.3.2
 * status:  assigned => needs_review


Comment:

 My changes for this are in my `fix/1839-rotation-periods`
 [https://gitweb.torproject.org/user/isis/bridgedb.git/log/?h=fix/1839
 -rotation-periods branch].

 There are now `HTTPS_ROTATION_PERIOD` and `EMAIL_ROTATION_PERIOD` config
 settings which may be used to control the hashring rotation periods for
 BridgeDB's distributors via the configuration file.

 The defaults for those settings will likely need to be changed and fiddled
 with to make the behaviour an optimum balance between user-friendly and
 resilient to enumeration. Currently, they are:

 {{{
 HTTPS_ROTATION_PERIOD = "3 hours"
 EMAIL_ROTATION_PERIOD = "1 day"
 }}}

 == Behavioural changes ==

 === Email Distributor ===

 The behaviour for hashring rotation for the `EmailBasedDistributor` is
 such that, when `bridgedb.email.autoresponder.createResponseBody()` calls
 `EmailBasedDistributor.getBridgesForEmail(EMAIL_ADDRESS, EPOCH)` with the
 `EPOCH` set to the start of the current `EMAIL_ROTATION_PERIOD`, the
 client's position in the hashring is determined by the HMAC of the string
 `"<EPOCH>EMAIL_ADDRESS"`.  Therefore, the `EMAIL_ROTATION_PERIOD` directly
 effects where the client is placed in the hashring, resulting in different
 bridges for that client, depending on whether the period has elapsed.

 With the default setting of `"1 day"`, and taking into account also that
 the EmailBasedDistributor only responds to a particular user once per
 three hours, this results in the client being able to ask for (and
 receive) vanilla bridges (starting from hashring position A) at 9:00,
 obfs3 bridges (also from position A) at 12:00, obfs4 bridges (from
 position A again) at 15:00, and so on, and finally different vanilla
 bridges (from hashring position B) the next morning at 9:00.

 === HTTPS Distributor ===

 For the `IPBasedDistributor`, the behaviour for hashring rotation is that
 the client's hashring position is determined by the HMAC of the string
 `"<EPOCH>AREA"` where `EPOCH` is the start of the current
 `HTTPS_ROTATION_PERIOD`, and the `AREA` is the `/16` subnet which the
 client's IP address resides within.  If the client is using Tor or some
 other open proxy, then the client's hashring position is determined by
 `"known-proxy<EPOCH>GROUP"` where `EPOCH` is the same as before, and
 `GROUP` is an integer (currently 1 through 4, inclusive) deterministically
 derived from the IP address of the Tor Exit relay or open proxy that the
 client is using. Using `GROUP` causes there to only be 4 sets of bridges
 available to any and all Tor/proxy users at a given time.  Hence
 additionally using `EPOCH` rotates the set of 4 bridges available.

 The default setting is `"3 hours"`, causing all Tor/proxy users to have 4
 different sets of bridges every three hours, while non-Tor users have a
 new set of bridges (probably) unique to their `/16` subnet of their IP
 address available every three hours.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1839#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online