On 2012-03-22, Mike Perry mikeperry@torproject.org wrote:
Thus spake Robert Ransom (rransom.8774@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:
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.)
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