[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #1839 [BridgeDB]: Rotate available bridges over time
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs