- tor-dev - lists.torproject.org

Proposal: Integration of BridgeFinder and BridgeFinderHelper
by Mike Perry 27 Mar '12

27 Mar '12

The following proposal should complete SponsorF tickets #5010-5012. I've pushed the proposal to my torspec.git branch mikeperry/bridgefinder, since the POSTMESSAGE Proposal ended up with some garbling at somewhere along the cut and paste chain. That branch also contains fixes for the POSTMESSAGE proposal's garbling. Filename: xxx-bridgefinder-integration.txt Title: Integration of BridgeFinder and BridgeFinderHelper Author: Mike Perry Created: 18-03-2012 Status: Proposed 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 may not require event driven operation, depending on POSTMESSAGE implementation status (POSTMESSAGE is designed to support both command and event driven operation, but it is possible event driven operation will happen first). 4. BridgeFinderHelper Each BridgeFinder implementation can optionally communicate with one or more BridgeFinderHelpers. BridgeFinderHelpers are plugins to external 3rd party applications that can inspect traffic, handle mime types, or implement protocol handlers for accepting bridge discovery information to pass to BridgeFinder. Example 3rd party applications include Chrome, World of Warcraft, QR Code readers, or simple cut and paste. Due to the arbitrary nature of sandboxing that may be present in various BridgeFinderHelper host applications, we do not mandate the exact nature of the IPC between BridgeFinder instances and external BridgeFinderHelper addons. However, please see the "Security Concerns" section for common pitfalls to avoid. 5. Tor Browser This is the browser the user uses with Tor. It is not useful until Tor is properly configured to use bridges. It fails closed. It is not expected to run BridgeFinderHelper plugin instances, unless those plugin instances exist to ensure the user always has a pool of working bridges available after successfully configuring an initial bridge. Once all bridges fail, the Tor Browser is useless. 6. Non-Tor Browser (aka BridgeFinderHelper host) This is the program the user uses for normal Internet activity to obtain bridges via a BridgeFinderHelper plugin. It does not have to be a browser. In advanced scenarios, this component may not be a browser at all, but may be a program such as World of Warcraft instead. Incremental Deployability The system is designed to be incrementally deployable: Simple designs should be possible to develop and test immediately. The design is flexible enough to be easily upgraded as more advanced features become available from both Tor and new pluggable transports. Initial Implementation In the simplest possible initial implementation, BridgeFinder will only discover Tor Bridges as they are deployed today. It will use the Tor Control Port to configure these bridges directly via the SETCONF command. It may or may not receive bridge information from a BridgeFinderHelper. In an even more degenerate case, BridgeFinderHelper may even be Vidalia or Orbot itself, acting upon user input from cut and paste. Initial Implementation: BridgeFinder Launch In the initial implementation, the Primary Controller will launch one or more BridgeFinders, providing control port authentication information to them through the environment variables TOR_CONTROL_PORT and TOR_CONTROL_PASSWD. BridgeFinder will then directly connect to the control port and authenticate. Initial implementations should be able to function without using SETEVENTS, and instead only using command-based status inquiries and configuration (GETINFO and SETCONF). Initial Implementation: Obtaining Bridge Hint Information In the initial implementation, to test functionality, BridgeFinderHelper can simply scrape bridges directly from https://bridges.torproject.org. In slightly more advanced implementations, a BridgeFinderHelper instance may be written for use in the user's Non-Tor Browser. This plugin could extract bridges from images, html comments, and other material present in ad banners and slack space on unrelated pages. BridgeFinderHelper would then communicate with the appropriate BridgeFinder instance over an acceptable IPC mechanism. This proposal does not seek to specify the nature of that IPC channel (because BridgeFinderHelper may be arbitrarily constrained due to host application sandboxing), but we do make several security recommendations under the section "Security Concerns: BridgeFinder and BridgeFinderHelper". Initial Implementation: Configuring New Bridges In the initial implementation, Bridge configuration will be done directly though the control port using the SETCONF command. Initial implementations will support only retrieval and configuration of standard Tor Bridges. These are configured using SETCONF on the Tor Control Port as follows: SETCONF Bridge="IP:ORPort [fingerprint]" Future Implementations In future implementations, the system can incrementally evolve in a few different directions. As new pluggable transports are created, it is conceivable that BridgeFinder may want to download new plugin binaries (and/or new transport transform definition files) and provide them to Tor. Furthermore, it may prove simpler to deploy multiple concurrent BridgeFinder+BridgeFinderHelper pairs as opposed to adding new functionality to existing prototypes. Finally, it is desirable for BridgeFinder to obtain approval from the user before updating bridge configuration, especially for cases where BridgeFinderHelper is automatically discovering bridges in-band during Non-Tor activity. The exact mechanisms for accomplishing these improvements is described in the following subsections. Future Implementations: BridgeFinder Launch and POSTMESSAGE handshake The nature of the BridgeFinder launch and the environment variables provided is not expected to change. However, future Primary Controller implementations may decide to launch more than one BridgeFinder instance side by side. Additionally, to negotiate the IPC channel created by Proposal 197 for purposes of providing user confirmation, it is recommended that BridgeFinder and the Primary Controller perform a handshake using POSTMESSAGE upon launch, to establish that all parties properly support the feature: Primary Controller: "POSTMESSAGE @all Controller wants POSTMESSAGE v1.1" BridgeFinder: "POSTMESSAGE @all BridgeFinder has POSTMESSAGE v1.0" Primary Controller: "POSTMESSAGE @all Controller expects POSTMESSAGE v1.0" BridgeFinder: "POSTMESSAGE @all BridgeFinder will POSTMESSAGE v1.0" If this 4 step handshake proceeds with an acceptable version, BridgeFinder must use POSTMESSAGE to transmit SETCONF Bridge lines (see "Future Implementations: Configuring New Bridges" below). If POSTMESSAGE support is expected, but the handshake does not complete for any reason, BridgeFinder should either exit or go dormant. The exact nature of the version negotiation and exactly how much backwards compatibility must be tolerated is unspecified. "All-or-nothing" is a safe assumption to get started. Future Implementations: Obtaining Bridge Hint Information Future BridgeFinder implementations may download additional information based on what is provided by BridgeFinderHelper. They may fetch pluggable transport plugins, transformation parameters, and other material. Future Implementations: Configuring New Bridges Future implementations will be concerned with providing two new pieces of functionality with respect to configuring bridges: configuring pluggable transports, and properly prompting the user before altering Tor configuration. There are two ways to tell Tor clients about pluggable transports (as defined in Proposal 180). On the control port, an external Proposal 180 transport will be configured with SETCONF ClientTransportPlugin=<method> socks5 <addr:port> [auth=X] as in SETCONF ClientTransportPlugin="trebuchet socks5 127.0.0.1:9999". A managed proxy is configured with SETCONF ClientTransportPlugin=<methods> exec <path> [options] as in SETCONF ClientTransportPlugin="trebuchet exec /usr/libexec/trebuchet --managed". This example tells Tor to launch an external program to provide a socks proxy for 'trebuchet' connections. The Tor client only launches one instance of each external program with a given set of options, even if the same executable and options are listed for more than one method. Pluggable transport bridges discovered for this transport by BridgeFinder would then be set with: SETCONF Bridge="trebuchet 3.2.4.1:8080 keyid=09F911029D74E35BD84156C5635688C009F909F9 rocks=20 height=5.6m". For more information on pluggable transports and supporting Tor configuration commands, see Proposal 180. Future Implementations: POSTMESSAGE and User Confirmation Because configuring even normal bridges alone can expose the user to attacks, it is strongly desired to provide some mechanism to allow the user to approve new bridges prior to their use, especially for situations where BridgeFinderHelper is extracting them transparently while the user performs unrelated activity. If BridgeFinderHelper grows to the point where it is downloading new transform definitions or plugins, user confirmation becomes absolutely required. To achieve user confirmation, we depend upon the POSTMESSAGE command defined in Proposal 197. If the POSTMESSAGE handshake succeeds, instead of sending SETCONF commands directly to the control port, the commands will be wrapped inside a POSTMESSAGE: POSTMESSAGE @all SETCONF Bridge="www.example.com:8284" Upon receiving this POSTMESSAGE, the Primary Controller will validate it, evaluate it, store it to be later enabled by the user, and alert the user that new bridges are available for approval. It is only after the user has approved the new bridges that the Primary Controller should then re-issue the SETCONF commands to configure and deploy them in the tor client. Additionally, see "Security Concerns: Primary Controller" for more discussion on potential pitfalls with POSTMESSAGE. Security Concerns While automatic bridge discovery and configuration is quite compelling and powerful, there are several serious security concerns that warrant extreme care. We've broken them down by component. Security Concerns: Primary Controller In the initial implementation, Orbot and Vidalia must take care to transmit the Tor Control password to BridgeFinder in such a way that it does not end up in system logs, process list, or viewable by other system users. The best known strategy for doing this is by passing the information through exported environment variables. Additionally, in future implementations, Orbot and Vidalia will need to validate Proposal 197 POSTMESSAGE input before prompting the user. POSTMESSAGE is a free-form message-passing mechanism. All sorts of unexpected input may be passed through it by any other authenticated Tor Controllers for their own unrelated communication purposes. Minimal validation includes verifying that the POSTMESSAGE data is a valid Bridge or ClientTransportPlugin line and is acceptable input for SETCONF. All unexpected characters should be removed through using a whitelist, and format and structure should be checked against a regular expression. Additionally, the POSTMESSAGE string should not be passed through any string processing engines that automatically decode character escape encodings, to avoid arbitrary control port execution. At the same time, POSTMESSAGE validation should be light. While fully untrusted input is not expected due to the need for control port authentication and BridgeFinder sanitation, complicated manual string parsing techniques during validation should be avoided. Perform simple easy-to-verify whitelist-based checks, and ignore unrecognized input. Beyond POSTMESSAGE validation, the manner in which the Primary Controller achieves consent from the user is absolutely crucial to security under this scheme. A simple "OK/Cancel" dialog is insufficient to protect the user from the dangers of switching bridges and running new plugins automatically. Newly discovered bridge lines from POSTMESSAGE should be added to a disabled set that the user must navigate to as an independent window apart from any confirmation dialog. The user must then explicitly enable recently added plugins by checking them off individually. We need the user's brain to be fully engaged and aware that it is interacting with Tor during this step. If they get an "OK/Cancel" popup that interrupts their online game play, they will almost certainly simply click "OK" just to get back to the game quickly. The Primary Controller should transmit the POSTMESSAGE content to the control port only after obtaining this out-of-band approval. Security Concerns: BridgeFinder and BridgeFinderHelper The unspecified nature of the IPC channel between BridgeFinder and BridgeFinderHelper makes it difficult to make concrete security suggestions. However, from past experience, the following best practices must be employed to avoid security vulnerabilities: 1. Define a non-webby handshake and/or perform authentication 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. Additionally, if possible, it is wise to establish a shared secret between BridgeFinder and BridgeFinderHelper through the filesystem or any other means available for use in authentication. For an a good example on how to use such a shared secret properly for authentication, see Trac Ticket #5185 and/or the SafeCookie Tor Control Port authentication mechanism. 2. Perform validation before parsing Care must 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. The input should be subjected to a character whitelist and possibly also validated against a regular expression to verify format, and if any unexpected or poorly-formed data is encountered, the IPC channel must be closed. 3. Fail closed on unexpected input If the handshake fails, or if any other part of the BridgeFinderHelper input is invalid, the IPC channel must be abandoned and closed. Do *not* continue scanning for good input after any bad input has been encountered. -- Mike Perry

4 12

Improving Tor Hidden Services
by Arturo Filastò 27 Mar '12

27 Mar '12

Setting aside the issue related with usability there are also some interesting improvements that can be made to make Tor HS more performant. I will summarize here the ideas that have been brought forward along with some that are not detailed anywhere and would like to see more interest in. I would suggest to start collecting all the information regarded to Tor HS improvements on this wiki page: https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/HiddenServic…. With respect to what is already on that page I got some feedback from rransom on those two items on IRC, but I did not note them down. It would be good if you were to summarize the critiques here or on the wiki page. Also there are a set of proposals that are related to Tor HS improvements that have been abandoned for some time and I believe it would be useful to summarize them inside of that wiki page. The proposals are: #121 Filename: 121-hidden-service-authentication.txt Title: Hidden Service Authentication https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/121-hidden-s… #142 Filename: 142-combine-intro-and-rend-points.txt Title: Combine Introduction and Rendezvous Points https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/142-combine-… #143 Filename: 143-distributed-storage-improvements.txt Title: Improvements of Distributed Storage for Tor Hidden Service Descriptors https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/143-distribu… #155 Filename: 155-four-hidden-service-improvements.txt Title: Four Improvements of Hidden Service Performance https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/155-four-hid… #194 Filename: 194-mnemonic-urls.txt Title: Mnemonic .onion URLs https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/194-mnemonic… and also this inside of the ideas, that is loosely related to #194, but instead of offering an encoding it offers a petname system: Filename: xxx-onion-nyms.txt Title: .onion nym system https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-on… The single most important thing I believe is needed in Tor Hidden Service is Encrypted services. These can be seen, in a way, as the reverse of Tor2web mode. It allows people to publish Hidden Services with no anonymity, but have the Tor end-to-end encryption and performance improvements. I see these to be the future of what was previously done, poorly, with Tor Exit Enclaves. One that wishes to have an end-to-end encrypted tunnel from Tor clients can run an encrypted service and have a reduced number of hops from the IP and RP. Roger started writing up a spec on this and it can be found here: Filename: xxx-encrypted-services.txt Title: Encrypted services as a replacement to exit enclaving https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-en… - Art.

2 1

Implement JSONP interface for check.torproject.org
by Arturo Filastò 26 Mar '12

26 Mar '12

I have made a patch to check.torproject.org to expose a JSONP interface that would allow people to have the user check client side if (s)he is using Tor. This would allow people to embed a badge on their website (privacybadge.html) that congratulates the user of using Tor or warns him of non Tor usage with a link to torproject.org. I can imagine privacy advocates having this deployed on their websites or systems that engourage users to connect to them anonymously. Compared to what check.torproject.org does at the moment the risk does not change, it is erogating exactly the same service, just making it more useful and flexible. Basically what it does is check if the ip doing the connection is connected through Tor. The web service will reply with a JSON encoded array that can be loaded from the user and display in the browser a nice looking badge. You can see how this works on the live demo hosted here: http://hellais.github.com/torcheck/privacybadge.html I still need to finish the styling of the badge to contain links to torproject.org and generally make it cooler. Also, the check.torproject repo should be moved to svn. - Art.

4 10

Proposal 198: Restore semantics of TLS ClientHello
by Nick Mathewson 26 Mar '12

26 Mar '12

Filename: 198-restore-clienthello-semantics.txt Title: Restore semantics of TLS ClientHello Author: Nick Mathewson Created: 19-Mar-2012 Status: Open Overview: Currently, all supported Tor versions try to imitate an older version of Firefox when advertising ciphers in their TLS ClientHello. This feature is intended to make it harder for a censor to distinguish a Tor client from other TLS traffic. Unfortunately, it makes the contents of the ClientHello unreliable: a server cannot conclude that a cipher is really supported by a Tor client simply because it is advertised in the ClientHello. This proposal suggests an approach for restoring sanity to our use of ClientHello, so that we still avoid ciphersuite-based fingerprinting, but allow nodes to negotiate better ciphersuites than they are allowed to negotiate today. Background reading: Section 2 of tor-spec.txt 2 describes our current baroque link negotiation scheme. Proposals 176 and 184 describe more information about how it got that way. Bug 4744 is a big part of the motivation for this proposal: we want to allow Tors to advertise even more ciphers, some of which we would actually prefer to the ones we are using now. What you need to know about the TLS handshake is that the client sends a list of all the ciphersuites that it supports in its ClientHello message, and then the server chooses one and tells the client which one it picked. Motivation and constraints: We'd like to use some of the ECDHE TLS ciphersuites, since they allow us to get better forward-secrecy at lower cost than our current DH-1024 usage. But right now, we can't ever use them, since Tor will advertise them whether or not it has a version of OpenSSL that supports them. (OpenSSL before 1.0.0 did not support ECDHE ciphersuites; OpenSSL before 1.0.0e or so had some security issues with them.) We cannot have the rule be "Tors must only advertise ciphersuites that they can use", since current Tors will advertise such ciphersuites anyway. We cannot have the rule be "Tors must support every ECDHE ciphersuite on the following list", since current Tors don't do all that, and since one prominent Linux distribution builds OpenSSL without ECC support because of patent/freedom fears. Fortunately, nearly every ciphersuite that we would like to advertise to imitate FF8 (see bug 4744) is currently supported by OpenSSL 1.0.0 and later. This enables the following proposal to work: Proposed spec changes: I propose that the rules for handling ciphersuites at the server side become the following: If the ciphersuites in the ClientHello contains no ciphers other than the following[*], they indicate that the Tor v1 link protocol is in use. TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA If the advertised ciphersuites in the ClientHello are _exactly_[*] the following, they indicate that the Tor v2+ link protocol is in use, AND that the ClientHello may have unsupported ciphers. In this case, the server may choose DHE_RSA_WITH_AES_128_CBC_SHA or DHE_RSA_WITH_AES_256_SHA, but may not choose any other cipher. TLS1_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS1_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS1_DHE_RSA_WITH_AES_256_SHA TLS1_DHE_DSS_WITH_AES_256_SHA TLS1_ECDH_RSA_WITH_AES_256_CBC_SHA TLS1_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLS1_RSA_WITH_AES_256_SHA TLS1_ECDHE_ECDSA_WITH_RC4_128_SHA TLS1_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS1_ECDHE_RSA_WITH_RC4_128_SHA TLS1_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS1_DHE_RSA_WITH_AES_128_SHA TLS1_DHE_DSS_WITH_AES_128_SHA TLS1_ECDH_RSA_WITH_RC4_128_SHA TLS1_ECDH_RSA_WITH_AES_128_CBC_SHA TLS1_ECDH_ECDSA_WITH_RC4_128_SHA TLS1_ECDH_ECDSA_WITH_AES_128_CBC_SHA SSL3_RSA_RC4_128_MD5 SSL3_RSA_RC4_128_SHA TLS1_RSA_WITH_AES_128_SHA TLS1_ECDHE_ECDSA_WITH_DES_192_CBC3_SHA TLS1_ECDHE_RSA_WITH_DES_192_CBC3_SHA SSL3_EDH_RSA_DES_192_CBC3_SHA SSL3_EDH_DSS_DES_192_CBC3_SHA TLS1_ECDH_RSA_WITH_DES_192_CBC3_SHA TLS1_ECDH_ECDSA_WITH_DES_192_CBC3_SHA SSL3_RSA_FIPS_WITH_3DES_EDE_CBC_SHA SSL3_RSA_DES_192_CBC3_SHA [*] The "extended renegotiation is supported" ciphersuite, 0x00ff, is not counted when checking the list of ciphersuites. Otherwise, the ClientHello has these semantics: The inclusion of any cipher supported by OpenSSL 1.0.0 means that the client supports it, with the exception of SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA which is never supported. Clients MUST advertise support for at least one of TLS_DHE_RSA_WITH_AES_256_CBC_SHA or TLS_DHE_RSA_WITH_AES_128_CBC_SHA. The server MUST choose a ciphersuite with ephemeral keys for forward secrecy; MUST NOT choose a weak or null ciphersuite; and SHOULD NOT choose any cipher other than AES or 3DES. Discussion and consequences: Currently, OpenSSL 1.0.0 (in its default configuration) supports every cipher that we would need in order to give the same list as Firefox versions 8 through 11 give in their default configuration, with the exception of the FIPS ciphersuite above. Therefore, we will be able to fake the new ciphersuite list correctly in all of our bundles that include OpenSSL, and on every version of Unix that keeps up-to-date. However, versions of Tor compiled to use older versions of OpenSSL, or versions of OpenSSL with some ciphersuites disabled, will no longer give the same ciphersuite lists as other versions of Tor. On these platforms, Tor clients will no longer impersonate Firefox. Users who need to do so will have to download one of our bundles, or use a (non-system) OpenSSL. The proposed spec change above tries to future-proof ourselves by not declaring that we support every declared cipher, in case we someday need to handle a new Firefox version. If a new Firefox version comes out that uses ciphers not supported by OpenSSL 1.0.0, we will need to define whether clients may advertise its ciphers without supporting them; but existing servers will continue working whether we decide yes or no. The restriction to "servers SHOULD only pick AES or 3DES" is meant to reflect our current behavior, not to represent a permanent refusal to support other ciphers. We can revisit it later as appropriate, if for some bizarre reason Camellia or Seed or Aria becomes a better bet than AES. Open questions: Should the client drop connections if the server chooses a bad cipher, or a suite without forward secrecy? Can we get OpenSSL to support the dubious FIPS suite excluded above, in order to remove a distinguishing opportunity? It is not so simple as just editing the SSL_CIPHER list in s3_lib.c, since the nonstandard SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA cipher is (IIUC) defined to use the TLS1 KDF, while declaring itself to be an SSL cipher (!). Can we do anything to eventually allow the IE7+[**] cipher list as well? IE does not support TLS_DHE_RSA_WITH_AES_{256,128}_SHA or SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, and so wouldn't work with current Tor servers, which _only_ support those. It looks like the only forward-secure ciphersuites that IE7+ *does* support are ECDHE ones, and DHE+DSS ones. So if we want this flexibility, we could mandate server-side ECDHE, or somehow get DHE+DSS support (which would play havoc with our current certificate generation code IIUC), or say that it is sometimes acceptable to have a non-forward-secure link protocol[***]. None of these answers seems like a great one. Is one best? Are there other options? [**] Actually, I think it's the Windows SChannel cipher list we should be looking at here. [***] If we did _that_, we'd want to specify that CREATE_FAST could never be used on a non-forward-secure link. Even so, I don't like the implications of leaking cell types and circuit IDs to a future compromise.

5 7

Missing methodname in proposal 180 example
by David Fifield 26 Mar '12

26 Mar '12

I found a little typo in proposal 180. David Fifield

2 1

Self publishing over Tor Hidden Services
by Arturo Filastò 25 Mar '12

25 Mar '12

Tor Hidden Services are great, though their impact is grossly limited by the fact that they are not at all easy to deploy. Systems such as Tor2web allow people that decide to publish anonymously to be reachable by anybody not using a Tor client. For dealing with the usability aspect of Tor Hidden Services, this GSoC I am going to be mentoring APAF: Anonymous Python Application Framework. The goal is to give easy to use tools for people to do self publishing. This is a basic description of the project: 1. Overview Tor Hidden Services are underused compared to their potential, the goal of APAF is to provide an easy system to allow network related python application developers to build their software in a way that it runs as a Tor Hidden Service (Tor HS). The framework will allow developers to easily build .exe, .app, statically linked linux binaries that contain the python interpreter and the Tor daemon. This will allow the end user to easily start running that service on their machine, by simply downloading a package. This is similar to what is done with the Tor Browser Bundle (TBB). 2. Motivation One of the reasons for which Tor HS are not used that much is that there is no simple way for an application developer to ship their application with a Tor binary and automatically configure a Tor HS. This leads to users not being able to easily run Tor Hidden Services on their desktop machines limiting the diffusion of HSs. An example use case is a person that wishes to run a temporary chat server on their home machine. With APAF a chat server developer could package such a python application and the end user will be able to run it by downloading a package and executing it. 3. What is built? APAF compiles all the dependencies for all the target systems. The software that will come bundled with it are: * the Python interpreter (cpython bundled with PyInstaller: http://www.pyinstaller.org/) * Tor * The desired python dependecies (computed with PyInstaller) The build system must be configurable and extensible. It should allow easy bundling of third party applications such as p7zip, gpg, etc as APAF modules, in order to let the project grow with new functionalities. The output of the build process will be: - Win32: MyApplication.exe - OSX: MyApplication.app (inside an Application.dmg container) - Linux: Deb build or statically linked binary The buildsystem should download the latest release of Tor for the appropriate platform and extract the required files into the build structure, in order to be packaged within the application. Note: Another possibility is that it could build Tor from source for the desired target platforms, but this may require some additional effort. 4. What happens when I start APAF? When APAF starts the user running it is presented with a splash screen that displays the startup progress. The image in the splash screen should be customizable by the application developer. Another option would be to start the system browser and point it to http://127.0.0.1:<APAF_port>/ and display the bootstrap process inside of the bundled web based UI. At first launch APAF will show a startup splash screen with a progress bar describing application startup event informations, optionally displaying an image. Then the system browser will be started to let the user access APAF UI, that will provide a wizard for bootstrapping the setup of the Tor Hidden Service. If the APAF application is already running by clicking on it, it will just start the browser to open directly the APAF UI. By default APAF will come with a web application that is used for administering and checking on the status of the running Tor HS. It should provide functionality the following functionality: * Check the current status of the Tor HS (it's hostname and port mapping) * Start and stop tor Hidden Service * API to add/remove new Tor Hidden service mapping * Select from the list of bundled applications the ones to run * Test it's reachability from the Tor network (by doing a request over Tor to it's .onion address) * Configure Tor (User Interface to edit torrc) * Close Awaf 5. Web Applications One of the first applications that will be used as an example for APAF will be a simple python web application. The application will simply serve to the client static files. The basic scaffolding that this web application provides should allow developers to build their own web application based on this example. The application will be written using TornadoWeb (http://www.tornadoweb.org/) 6. Security Features Outbound Connection Torrification --------------------------------- The framework must provide support to automatically torify all or specific outbound connection. The entire python application framework (Tornadoweb) should be forbidden to make any outbound connections directly, it should not leak out of the Tor network. Inbound Connection (Tor Hidden Service) --------------------------------------- APAF will expose to the Tor network the configured Tor Hidden Service running the bundled server software. The user will be able to properly configure their HS and choose if to allow connections from tor2web (in the case of a web application) or not. Misc. ---- Ideally the application should come with security enhancements such as sandboxing and hardening of the system to minimize anonymity leaks and security vulnerability exploitability. 7. Documentation APAF must provide detailed documentation on: - how to setup the build environment (eventually on multiple operating systems) - how to customize your own enviroment for your own anonymous web application - any specific documentation on particular procedures and/or internal structure - user manual for running an APAF built application Specific to Google Summer of Code the student will complete the following: For GSoC the student is expected to create the build system capable of building a simple web application that serves static files. It should also include a web UI for a wizard setup, checking the status of the HS and configuring it. I believe this project has some common goals with the work TAILS wants to do on the "TAILS server edition" [1]. I would be very interested in having feedback on this topic to manage to properly set the scope of the tasks to be done during GSoC. maker is interested in working on this project and we have been discussing it with him in the past days. - Art. [1] tails.boum.org/todo/server_edition/

2 1

Re: [tor-dev] Proposal 193: Safe cookie authentication
by Robert Ransom 22 Mar '12

22 Mar '12

I've pushed a revised protocol change to branch safecookie of git.tpo/rransom/torspec.git, and a (messy, needs rebase, untested) implementation to branch safecookie-023 of git.tpo/rransom/tor.git. Now, the client and server nonces are fed to the same HMAC invocation, so that the client can believe (modulo Merkle-Damgard and general iterative hash function ‘features’) that the server knows the cookie (rather than just HMAC(constant, cookie)). Almost all controllers must drop almost all support for non-safe cookie authentication ASAP, because a compromised system-wide Tor process could drop a symlink to /home/rransom/.ed25519-secret-key in where it was supposed to put a cookie file. The sole exception to ‘non-safe cookie authentication must die’ is when a controller knows that it is connected to a server process with equal or greater access to the same filesystem it has access to. In practice, this means ‘only if you're completely sure that Tor is running in the same user account as the controller, and you're completely sure that you're connected to Tor’, and no controller is sure of either of those. Robert Ransom

2 2

Proposal 200: Adding new, extensible CREATE, EXTEND, and related cells
by Nick Mathewson 22 Mar '12

22 Mar '12

Filename: 200-new-create-and-extend-cells.txt Title: Adding new, extensible CREATE, EXTEND, and related cells Author: Robert Ransom Created: 2012-03-22 Status: Open History The original draft of this proposal was from 2010-12-27; nickm revised it slightly on 2012-03-22 and added it as proposal 200. Overview and Motivation: In Tor's current circuit protocol, every field, including the 'onion skin', in the EXTEND relay cell has a fixed meaning and length. This prevents us from extending the current EXTEND cell to support IPv6 relays, efficient UDP-based link protocols, larger 'onion keys', new circuit-extension handshake protocols, or larger identity-key fingerprints. We will need to support all of these extensions in the near future. This proposal specifies a replacement EXTEND2 cell and related cells that provide more room for future extension. Design: FIXME - allocate command ID numbers (non-RELAY commands for CREATE2 and CREATED2; RELAY commands for EXTEND2 and EXTENDED2) The CREATE2 cell contains the following payload: Handshake type [2 bytes] Handshake data length [2 bytes] Handshake data [variable] The relay payload for an EXTEND2 relay cell contains the following payload: Number of link specifiers [1 byte] N times: Link specifier type [1 byte] Link specifier length [1 byte] Link specifier [variable] Handshake type [2 bytes] Handshake data length [2 bytes] Handshake data [variable] The CREATED2 cell and EXTENDED2 relay cell both contain the following payload: Handshake data length [2 bytes] Handshake data [variable] All four cell types are padded to 512-byte cells. When a relay X receives an EXTEND2 relay cell: * X finds or opens a link to the relay Y using the link target specifiers in the EXTEND2 relay cell; if X fails to open a link, it replies with a TRUNCATED relay cell. (FIXME: what do we do now?) * X copies the handshake type and data into a CREATE2 cell and sends it along the link to Y. * If the handshake data is valid, Y replies by sending a CREATED2 cell along the link to X; otherwise, Y replies with a TRUNCATED relay cell. (XXX: we currently use a DESTROY cell?) * X copies the contents of the CREATED2 cell into an EXTENDED2 relay cell and sends it along the circuit to the OP. Link target specifiers: The list of link target specifiers must include at least one address and at least one identity fingerprint, in a format that the extending node is known to recognize. The extending node MUST NOT accept the connection unless at least one identity matches, and should follow the current rules for making sure that addresses match. [00] TLS-over-TCP, IPv4 address A four-byte IPv4 address plus two-byte ORPort [01] TLS-over-TCP, IPv6 address A sixteen-byte IPv6 address plus two-byte ORPort [02] Legacy identity A 20-byte SHA1 identity fingerprint. At most one may be listed. As always, values are sent in network (big-endian) order. Legacy handshake type: The current "onionskin" handshake type is defined to be handshake type [00 00], or "legacy". The first (client->relay) message in a handshake of type “legacy” contains the following data: ‘Onion skin’ (as in CREATE cell) [DH_LEN+KEY_LEN+PK_PAD_LEN bytes] This value is generated and processed as sections 5.1 and 5.2 of tor-spec.txt specify for the current CREATE cell. The second (relay->client) message in a handshake of type “legacy” contains the following data: Relay DH public key [DH_LEN bytes] KH (see section 5.2 of tor-spec.txt) [HASH_LEN bytes] These values are generated and processed as sections 5.1 and 5.2 of tor-spec.txt specify for the current CREATED cell. After successfully completing a handshake of type “legacy”, the client and relay use the current relay cryptography protocol. Bugs: This specification does not accommodate: * circuit-extension handshakes requiring more than one round No circuit-extension handshake should ever require more than one round (i.e. more than one message from the client and one reply from the relay). We can easily extend the protocol to handle this, but we will never need to. * circuit-extension handshakes in which either message cannot fit in a single 512-byte cell along with the other required fields This can be handled by specifying a dummy handshake type whose data (sent from the client) consists of another handshake type and the beginning of the data required by that handshake type, and then using several (newly defined) HANDSHAKE_COMPLETION relay cells sent in each direction to transport the remaining handshake data. The specification of a HANDSHAKE_COMPLETION relay cell and its associated dummy handshake type can safely be postponed until we develop a circuit-extension handshake protocol that would require it. * link target specifiers that cause EXTEND2 cells to exceed 512 bytes This can be handled by specifying a LONG_COMMAND relay cell type that can be used to transport a large ‘virtual cell’ in multiple 512-byte cells. The specification of a LONG_COMMAND relay cell can safely be postponed until we develop a link target specifier, a RELAY_BEGIN2 relay cell and stream target specifier, or some other relay cell type that would require it.

1 0

Tor for iOS via official channels
by Linas Valiukas 21 Mar '12

21 Mar '12

Hello, I was thinking about a GSoC 2012 project I could propose, and I came to the question of why there's no Tor iOS (iPhone / iPad / iPod touch) application distributed on the official iTunes App Store? There's this "test package" of Tor for iOS available [1], but it has to be installed via Cydia and not everyone's phone is jailbroken. Distributing an application via the App Store has some benefits of its own too (additional marketing and visibility, easier installation, to name a few). So, what is the problem? * Would it comply with the iOS Developer Program License Agreement? I'm no lawyer, but last I read the document there's nothing in it that would prevent distributing an app which would create a "local" HTTP proxy to be used by the other applications. * Since the iPhone 3GS, the applications can retain running in the background, so I guess we're fine on the purely technical side too. * There are US Export laws that require a so-called CCATS review and approval to be done with each application that employs strong encryption. I don't think that's a blocker though. * Maybe that Tor iOS application wouldn't reach various "interesting" markets such as PRC (for example, a commercial yet pricy "Covert Browser" [2] is not available in China's App Store) because of the legal restrictions. Still, I would argue that it is worth having such an application. Regards, [1]: http://sid77.slackware.it/ios/ [2]: http://itunes.apple.com/us/app/covert-browser/id477438328?mt=8 -- Linas Valiukas +370 687 65870 www.pypt.lt

5 6

Re: [tor-dev] Proposal 198: Restore semantics of TLS ClientHello
by Jacob Appelbaum 21 Mar '12

21 Mar '12

On 03/20/2012 09:08 PM, Nick Mathewson wrote: > On Tue, Mar 20, 2012 at 11:57 PM, Jacob Appelbaum <jacob(a)appelbaum.net> wrote: > [...] >> Ah ha. That sounds like a nightmare. Is there a bug report we can pile >> on to request that they don't create a headache for everyone in the future? > > There is, but I don't currently see much point: their developers are > irritated, and know that other developers are irritated, and believe > that they can't take any actual action without word from their legal > department. > We can provide packages for users or a spec file for their users as an alternative, I guess? I think generally we're already doing this by providing the Tor Browser but all users with system tors are going to be left out... >>>> It seems that our integration with >>>> platforms is really heading in a bad direction. I'd like to figure out >>>> how to not diverge entirely and if possible to fix or document the issues. >>> >>> I don't know what you mean by "diverge" here -- do you mean that >>> different platforms may advertise different ciphers based on their >>> version of OpenSSL or whether their legal department fears ECC? If >>> so, then all non-Tor OpenSSL applications running on those hosts >>> already leak this information. >> >> I mean - Tor's cipher suite advertisement will be really wacky, >> basically on a platform by platform basis, version by version basis. >> What we expect to say about tor's fingerprint is less and less easy to >> say concisely, or perhaps it's easy but has a few variants? It seems >> like we'll have to track it more closely, perhaps by sniffing network >> traces on a per OS basis? > > It should be fairly easy to notice what ciphers we are really > advertising, and warn when it isn't the list we want to advertise. > Sure, it's just a simple matter of programming. ;-) > What we can expect to say about the fingerprint will be: "If you have > a default build of OpenSSL 1.0.0 or later, then you will look like > Firefox 8+ (modulo other issues not related to ciphersuites). If you > have an ECC-disabled build of OpenSSL 1.0.0 or later, then you will > look like FF8+ with all the ECC turned off. (I am pretty sure that > Fedora does indeed turn off the ECC in the Firefox they ship.) > Otherwise, if you have a really weird OpenSSL build, or an older > version of OpenSSL, your fingerprint will be weird." > I think that's a lot of stuff to say - we'll probably want to keep track of our various fingerprints somewhere - a bug or the wiki, perhaps? > [...] >> My thought was as follows - we have a >> pt_client{many-cipher-suites-support} that can be made to impersonate >> many browsers, it can try to connect to either relays which it can thus >> become Firefox without issue or to a bridge with this >> pt_server{many-cipher-suites-support} support and so it can pretend to >> be nearly anything. I probably should have made that suggestion more >> explicit. >> >> But yes, I agree, unless we can make the servers support the required >> ciphers, I think we're doomed. I didn't miss that, I was just trying to >> suggest a hack whereby we can impersonate IE as a pluggable transport. >> >> I've wondered for a while about cipher suites, specifically, why can't >> we just lie on the wire and then internally map ciphers as we like? For >> example - our client sends ECDHE but our server understands this is us >> trying as a client to impersonate IE and maps that to some other forward >> secret cipher suite like TLS_DHE_RSA_WITH_AES_128_SHA? I'm sure it's a >> TLS nightmare but, I guess it feels like we're heading there anyway...? > > Actually, we are heading AWAY from the TLS nightmare. That's the point > of this proposal: to minimize our use of ClientHello ciphersuite > fakery, so that the TLS ciphersuite negotiation handshake can > eventually just work again. > Well, OK, I think I understand that. Sorta. I agree that it is a step in the right direction but I do think it's a nightmare unless we have some way to basically make tor perform uniformly without us tracking things. Basically, we can impersonate a few browsers on the client side but the relays limit our ability to impersonate properly. It seems like a lot of stuff to keep track up, I already want a lookup table to know which version of tor, which version of openssl, which platform, etc to know what my handshake looks like and so on. It's not that complicated, it's just complicated enough though... > The idea above wouldn't work in any straightforward way: It is easy to > tell a DHE handshake from an ECDHE handshake -- for example, by > looking at the group parameters, which are sent in the clear! -- so if > the server says that it picks one but then the server and the client > do another, that would be really easy to detect. Ok, I admit, I had no idea that the group parameters were sent in the clear - I agree, just hacking up the cipher suites isn't actually useful in that case. Argh! All the best, Jake

1 0