[tor-dev] Proposal: Integration of BridgeFinder and BridgeFinderHelper
rransom.8774 at gmail.com
Thu Mar 22 02:48:02 UTC 2012
On 2012-03-22, Mike Perry <mikeperry at torproject.org> wrote:
> Thus spake Robert Ransom (rransom.8774 at gmail.com):
>> [ snip ]
> I've updated the proposal to address your concerns at
> I've relaxed some of the requirements a little, but I think I still
> properly cover everything you mentioned.
> Here's the updated proposal inline for more comment:
> 4. Exercise care with disk activity
> If transport plugins or definition/configuration files are to be
> downloaded, the BridgeFinder MUST ensure that they are only written to
> a known, controlled subdirectory of the Tor Browser Bundle, and with
> predictable extensions and properly applied permissions.
In particular, on platforms and filesystems which have an ‘execute
bit’ (primarily non-FAT filesystems on a Unixoid OS), the execute bit
MUST NOT be set on files which are not intended to be executed
directly by the operating system. (This *should* be obvious, but I'm
afraid that it isn't.)
> In particular, BridgeFinder MUST NOT create files with (entirely or
> partially) attacker-controlled contents or files with
> attacker-controlled names or file extensions.
Some reasons for this restriction are:
* An attacker can plant illegal data (e.g. pictures of naked ankles)
on a user's computer.
* An attacker can plant data which exploits bugs in code which a
file-manager application will apply to the contents of files in any
directory which the user browses to.
* An attacker could plant malicious software in a subdirectory of the
Tor Browser Bundle, and then persuade users to go run it.
If a user asks a BridgeFinder to store not-yet-authenticated data to
disk, I recommend that BridgeFinder ‘grizzle’ the data first. (See
http://www.cl.cam.ac.uk/~rja14/Papers/grizzle.pdf , and note that the
nonce and integrity check are *very* important here.)
> 5. Exercise care when operating from within Tor Browser
> Any BridgeFinderHelper operating from within Tor Browser MUST NOT
> use the same passive side-channel and/or steganographic techniques
> employed by the Non-Tor BridgeFinderHelper, as these types of
> techniques can be (ab)used by malicious exit nodes to deanonymize
> users by feeding them specific, malicious bridges.
I was worried about malicious content, not necessarily malicious exit
nodes or servers. (For example, They send e-mail containing one piece
of BridgeFinderHelper information to a dissident which They want to
locate, and spray the other pieces of information for Their malicious
bridge all over.)
> Any bridge discovery performed from within Tor Browser MUST be active
> in nature (with bridge sources fully controlled by BridgeFinderHelper)
> and MUST be authenticated (via TLS+cert pinning and/or HMAC).
Public-key signatures are better than either of those authentication methods.
> Further, a BridgeFinder or BridgeFinderHelper MAY make its own
> connections through Tor for the purpose of finding new bridge
> addresses (or updating previously acquired addresses), but MUST use
> Tor's stream isolation feature to separate BridgeFinder streams from
> the user's anonymous/pseudonymous activities.
More information about the tor-dev