Re: [tor-dev] Proposal: Integration of BridgeFinder and BridgeFinderHelper
On 2012-03-22, Mike Perry mikepe...@torproject.org wrote: Thus spake Robert Ransom (rransom.8...@gmail.com): [ snip ] Ok, attempt #2. This time I tried to get at the core of your concerns about attacker controlled input by requring some form of authentication on all bridge information that is to be automatically configured. I rewrote most of the ‘Security Concerns’ section for BridgeFinder/Helper. Please merge: https://git.torproject.org/rransom/torspec.git bridgefinder2 Security Concerns: BridgeFinder and BridgeFinderHelper 1. Do not allow attacks on your IPC channel by malicious local 'live data' The biggest risk is that unexpected applications will be manipulated into posting malformed data to the BridgeFinder's IPC channel as if it were from BridgeFinderHelper. The best way to defend against this is to require a handshake to properly complete before accepting input. If the handshake fails at any point, the IPC channel MUST be abandoned and closed. Do *not* continue scanning for good input after any bad input has been encountered; that practice may allow cross-protocol attacks by malicious JavaScript running in the user's non-Tor web browser. Additionally, it is wise to establish a shared secret between BridgeFinder and BridgeFinderHelper, using an environment variable if possible. For an a good example on how to use such a shared secret properly for authentication; see Tor ticket #5185 and/or the SAFECOOKIE Tor control port authentication method. 2. Do not allow attacks against the Controller Care has to be taken before converting BridgeFinderHelper data into Bridge lines, especially for cases where the BridgeFinderHelper data is fed directly to the control port after passing through BridgeFinder. In specific, the input MUST be subjected to a character whitelist and should also be validated against a regular expression to verify format, and if any unexpected or poorly-formed data is encountered, the IPC channel MUST be closed. Malicious control-port commands can completely destroy a user's anonymity. BridgeFinder is responsible for preventing strings which could plausibly cause execution of arbitrary control-port commands from reaching the Controller. 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. 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. 4. Exercise care with what is written to disk BridgeFinder developers must be aware of the following attacks, and ensure that their software does not expose users to any of them: * An attacker could plant
Re: [tor-dev] Proposal: Integration of BridgeFinder and BridgeFinderHelper
Thus spake Robert Ransom (rransom.8...@gmail.com): I rewrote most of the ‘Security Concerns’ section for BridgeFinder/Helper. Please merge: https://git.torproject.org/rransom/torspec.git bridgefinder2 Security Concerns: BridgeFinder and BridgeFinderHelper 1. Do not allow attacks on your IPC channel by malicious local 'live data' The biggest risk is that unexpected applications will be manipulated into posting malformed data to the BridgeFinder's IPC channel as if it were from BridgeFinderHelper. The best way to defend against this is to require a handshake to properly complete before accepting input. If the handshake fails at any point, the IPC channel MUST be abandoned and closed. Do *not* continue scanning for good input after any bad input has been encountered; that practice may allow cross-protocol attacks by malicious JavaScript running in the user's non-Tor web browser. Additionally, it is wise to establish a shared secret between BridgeFinder and BridgeFinderHelper, using an environment variable if possible. For an a good example on how to use such a shared secret properly for authentication; see Tor ticket #5185 and/or the SAFECOOKIE Tor control port authentication method. 2. Do not allow attacks against the Controller Care has to be taken before converting BridgeFinderHelper data into Bridge lines, especially for cases where the BridgeFinderHelper data is fed directly to the control port after passing through BridgeFinder. In specific, the input MUST be subjected to a character whitelist and should also be validated against a regular expression to verify format, and if any unexpected or poorly-formed data is encountered, the IPC channel MUST be closed. Malicious control-port commands can completely destroy a user's anonymity. BridgeFinder is responsible for preventing strings which could plausibly cause execution of arbitrary control-port commands from reaching the Controller. 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. It also feels weird to have this be a MUST, especially if we're not sure how it can be done right.. 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
Re: [tor-dev] Proposal: Integration of BridgeFinder and BridgeFinderHelper
Thus spake Robert Ransom (rransom.8...@gmail.com): [ snip ] Ok, attempt #2. This time I tried to get at the core of your concerns about attacker controlled input by requring some form of authentication on all bridge information that is to be automatically configured. I also added a requirement for end to end encryption to be performed on the content of any side channels that can be observed by exit nodes, and made a few other minor tweaks. Here's the diff (pushed to mikeperry/bridgefinder2 again): https://gitweb.torproject.org/user/mikeperry/torspec.git/commitdiff/f6fbb43bb59c921449c4f64f13fe26e15e3901dc And here's the full updated proposal again: Filename: 199-bridgefinder-integration.txt Title: Integration of BridgeFinder and BridgeFinderHelper Author: Mike Perry Reviewed-By: Robert Ransom Created: 18-03-2012 Status: Open Target: 0.2.3.x+ Overview This proposal describes how the Tor client software can interact with an external program that performs bridge discovery based on user input or information extracted from a web page, QR Code, online game, or other transmission medium. Scope and Audience This document describes how all of the components involved in bridge discovery communicate this information to the rest of the Tor software. The mechanisms of bridge discovery are not discussed, though the design aims to be generalized enough to allow arbitrary new discovery mechanisms to be added at any time. This document is also written with the hope that those who wish to implement BridgeFinder components and BridgeFinderHelpers can get started immediately after a read of this proposal, so that development of bridge discovery mechanisms can proceed in parallel to supporting functionality improvements in the Tor client software. Components and Responsibilities 0. Tor Client The Tor Client is the piece of software that connects to the Tor network (optionally using bridges) and provides a SOCKS proxy for use by the user. In initial implementations, the Tor Client will support only standard bridges. In later implementations, it is expected to support pluggable transports as defined by Proposal 180. 1. Tor Control Port The Tor Control Port provides commands to perform operations, configuration, and to obtain status information. It also optionally provides event driven status updates. In initial implementations, it will be used directly by BridgeFinder to configure bridge information via GETINFO and SETCONF. It is covered by control-spec.txt in the tor-specs git repository. In later implementations, it will support the inter-controller POSTMESSAGE IPC protocol as defined by Proposal 197 for use in conveying bridge information to the Primary Controller. 2. Primary Controller The Primary Controller is the program that launches and configures the Tor client, and monitors its status. On desktop platforms, this program is Vidalia, and it also launches the Tor Browser. On Android, this program is Orbot. Orbot does not launch a browser. On all platforms, this proposal requires that the Primary Controller will launch one or more BridgeFinder child processes and provide them with authentication information through the environment variables TOR_CONTROL_PORT and TOR_CONTROL_PASSWD. In later implementations, the Primary Controller will be expected to receive Bridge configuration information via the free-form POSTMESSAGE protocol from Proposal 197, validate that information, and hold that information for user approval. 3. BridgeFinder A BridgeFinder is a program that discovers bridges and configures Tor to use them. In initial implementations, it is likely to be very dumb, and its main purpose will be to serve as a layer of abstraction that should free the Primary Controller from having to directly implement numerous ways of retrieving bridges for various pluggable transports. In later implementations, it may perform arbitrary network operations to discover, authenticate to, and/or verify bridges, possibly using informational hints provided by one or more external BridgeFinderHelpers (see next component). It could even go so far as to download new pluggable transport plugins and/or transform definition files from arbitrary urls. It will be launched by the Primary Controller and given access to the Tor Control Port via the environment variables TOR_CONTROL_PORT and TOR_CONTROL_PASSWD. Initial control port interactions can be command driven via GETINFO and SETCONF, and do not need to subscribe to or process control port events. Later implementations will use POSTMESSAGE as defined in Proposal 197 to pass command requests to Vidalia, which will parse them and ask for user confirmation before deploying them. Use of POSTMESSAGE may or
Re: [tor-dev] Proposal: Integration of BridgeFinder and BridgeFinderHelper
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
Re: [tor-dev] Proposal: Integration of BridgeFinder and BridgeFinderHelper
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. I missed something: You need to use a protocol name other than “POSTMESSAGE” for the protocol which will be spoken over the POSTMESSAGE transport layer. If you aren't feeling creative, ‘pwgen -0A’ might help. Or look through a list of names of potential bikeshed colors. Robert Ransom ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
