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

[Robert Ransom <rransom.8774@xxxxxxxxx>]

On 2012-03-26, Mike Perry <mikeperry@xxxxxxxxxxxxxx> wrote:
> Thus spake Robert Ransom (rransom.8774@xxxxxxxxx):

>>   3. Provide information about bridge sources to users
>>
>>      BridgeFinder MUST provide complete information about how each
>>      bridge was obtained (who provided the bridge data, where the
>>      party which provided the data intended that it be sent to users,
>>      and what activities BridgeFinder extracted the data from) to
>>      users so that they can make an informed decision about whether to
>>      trust the bridge.
>
> I like the idea of passing bridge authentication + attribution up to
> Vidalia via POSTMESSAGE somehow. However, encoding it properly is likely
> to be problematic and situation-specific.

Perhaps you should have called your IPC command â+POSTMESSAGEâ.

> It also feels weird to have this be a MUST, especially if we're not sure
> how it can be done right..

It must be done, even if it requires a more thoroughly designed and
specified IPC protocol than you expected.


>>      BridgeFinder MUST authenticate, for every piece of discovered
>>      bridge data, the party which provided the bridge address, the
>>      party which prepared the bridge data in BridgeFinder's input
>>      format, and the time, location, and manner in which the latter
>>      party intended that the bridge data be distributed.  (Use of an
>>      interactive authentication protocol is not sufficient to
>>      authenticate the intended location and manner of distribution of
>>      the bridge data; those facts must be explicitly authenticated.)
>>
>>      These requirements are intended to prevent or mitigate several
>>      serious attacks, including the following:
>>
>>      * A malicious bridge can 'tag' its client's circuits so that a
>>        malicious exit node can easily recognize them, thereby
>>        associating the client with some or all of its anonymous or
>>        pseudonymous activities.  (This attack may be mitigated by new
>>        cryptographic protocols in a near-future version of Tor.)
>>
>>      * A malicious bridge can attempt to limit its client's knowledge
>>        of the Tor network, thereby biasing the client's path selection
>>        toward attacker-controlled relays.
>>
>>      * A piece of bridge data containing the address of a malicious
>>        bridge may be copied to distribution channels other than those
>>        through which it was intended to be distributed, in order to
>>        expose more clients to a particular malicious bridge.
>>
>>      * Pieces of bridge data containing the addresses of non-malicious
>>        bridges may be copied to other-than-intended distribution
>>        channels, in order to cause a particular client to attempt to
>>        connect to a known, unusual set of bridges, thus allowing a
>>        malicious ISP to monitor the client's movements to other
>>        network and/or physical locations.
>>
>>      BridgeFinder MUST warn users about the above attacks, and warn
>>      that other attacks may also be possible if users accept
>>      improperly distributed bridge data.
>
> Warning users about technically complicated potential attacks is
> unlikely to substantially protect them in practice, and will have many
> negative consequences wrt usability... There is a right place to
> document this stuff, but I'm not sure the BridgeFinder app itself is
> that place.

I expect that a bridge datum's distribution channel will need to be
âfuzzy-matchedâ to the location where a user received it.  That will
require, at a minimum, telling the user where/how the datum was
intended to be distributed, where/how it actually was distributed to
the user, and that if those items do not match, the user should throw
away that datum.

> Warning in the event of unexpected behavior that actually happens is a
> good plan. But this again is something that requires another channel
> through Vidalia. I doubt most BridgeFinders will have guis :/
>
> We could define a new POSTMESSAGE type "Alert" for example, so Vidalia
> can inform the user of something fishy on behalf of BridgeFinder? But
> that brings up localization issues... Do we leave it to BridgeFinder
> implementations to specify error codes to be sent over POSTMESSAGE, or
> do we leave it free-form?

I like the R6RS âconditionsâ system as a way to handle error codes in
protocols.  You probably don't need a fancy encoding that can handle
arbitrary S-expressions; a list of strings should be sufficient, with
conditions which have associated data (e.g. a fallback message in
English for use if the controller doesn't have a better message that
matches the error) represented as the condition type followed by a
colon followed by the associated data (e.g. âmessage-en:The sky is
falling!â).


>>   5. Exercise care with where things are written to disk
>>
>>      The Tor Browser Bundle is designed to not leave traces that it
>>      has been run on a computer outside the directory in which it was
>>      unpacked, and, to the extent possible, to mitigate any such
>>      traces left by the operating system.
>>
>>      BridgeFinder MUST NOT write data to disk outside the Tor Browser
>>      Bundle directory at any time.  BridgeFinder MUST NOT use any
>>      operating system features which are known to write data to disk
>>      outside the Tor Browser Bundle directory.
>>
>>      If BridgeFinderHelper operates as an extension of a program which
>>      the user has installed on his/her/its computer, it (or
>>      configuration data needed to cause the non-Tor Browser to load
>>      it) may need to be installed outside the Tor Browser Bundle
>>      directory.  However, BridgeFinderHelper SHOULD NOT write data to
>>      disk or cause data to be written to disk outside the TBB directory.
>>
>>      BridgeFinderHelper MUST NOT be installed outside the TBB
>>      directory, and MUST NOT write data to disk, unless the user has
>>      explicitly permitted that.
>
> The above paragraph makes many otherwise useful BridgeFinderHelpers
> impossible to implement in practice. It also contradicts the preceding
> paragraph in terms of MUST vs SHOULD.
>
> In specific, Chrome addons are installed into the user's Chrome profile
> directory (unless you run them in 'unpacked' mode, which no one will do). I
> believe WoW addons are similar wrt restricted installation paths. There
> likely won't be a way to run BridgeFinderHelper plugins for these
> platforms from inside of the TBB dir.
>
> Unless this is just a typo and you meant BridgeFinder above?

It's not a typo.  Those BridgeFinderHelpers MUST NOT be installed
unless the user has explicitly permitted that they be installed.  Even
if the user has explicitly permitted that a BridgeFinderHelper be
installed and write data to disk, it SHOULD NOT write data to disk if
that is not absolutely necessary.

>>      BridgeFinder, BridgeFinderHelper, and their installation
>>      routines, MUST warn users that traces written to a disk cannot be
>>      erased without erasing the entire filesystem before asking for
>>      permission to write outside the TBB directory.  (The user has
>>      already chosen to leave traces of TBB in the directory it was
>>      unpacked into.)

>>   8. Do not stick beans up the user's nose
>>
>>      Deployed versions of BridgeFinder and BridgeFinderHelper MUST NOT
>>      have any debugging features which cause them to log sensitive
>>      data to disk.  Someone *will* turn them on, whether by accident
>>      or by malice.
>>
>>      Development versions of BridgeFinder and BridgeFinderHelper which
>>      have such debugging features MUST warn users that they are
>>      development builds and should not be used by non-developers.
>
> Requiring users to run special development builds to get any logs is
> going to mean we won't ever get any logs when things break. I think
> we're hamstringing ourselves development-wise with this rather silly
> compile-time requirement.

Or it will mean that the logs you get (and which were written to the
user's disk before the user had any idea what would be in them) will
not contain sensitive data.

Or it will mean that a user will have to collect logs in memory with a
debugging tool, and then paste the logs into their MUA.  This sounds
*more* useful to developers than spamming the user's disk with
sensitive data.

> Perhaps instead we should recommend a log scrubbing mechanism similar to
> the ones used by Tor and Torbutton.

That is one way to not write sensitive data to disk.



Robert Ransom
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev