On 2012-03-22, Mike Perry <mikepe...@torproject.org> wrote: > Thus spake Robert Ransom (rransom.8...@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 _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
