[tor-dev] Proposal: Integration of BridgeFinder and BridgeFinderHelper

[Robert Ransom]

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
> mikeperry/bridgefinder2.
>
> I've relaxed some of the requirements a little, but I think I still
> properly cover everything you mentioned.

Yes.

> 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.



Robert Ransom