Re: [tor-dev] Implement JSONP interface for check.torproject.org
Resurrecting a thread from the grave! 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. Since I noticed that check.tpo was removed from the front page I was thinking it would be a good idea to bring back up the topic of migrating check.torproject.org to a JSONP based system. Such a system would also allow to have the JSONP check nodes distributed across multiple machines (avoiding the single point of failure that check currently is) and the client side software could be embedded inside of TBB directly. People could further promote the usage of Tor by placing an Anonymity badge on their website. A person wishing to setup such a node needs to simply install TorBel and a python based web app that runs this JSONP system. My threat model for this is very lax, so I don't see any purpose in bad actors telling a client when he is not using Tor that he is using it. If check.tpo tells the user is not using Tor it already means that TBB failed, the purpose of it is just to provide visual feedback to the user that all is did went well. 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. Isn't it already in svn? Shouldn't we move it to git? If check is moved to git and you think it is a good idea I can start working on this. - Art. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Self publishing over Tor Hidden Services
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
[tor-dev] Improving Tor Hidden Services
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/HiddenServices. 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-service-authentication.txt #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-intro-and-rend-points.txt #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-distributed-storage-improvements.txt #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-hidden-service-improvements.txt #194 Filename: 194-mnemonic-urls.txt Title: Mnemonic .onion URLs https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/194-mnemonic-urls.txt 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-onion-nyms.txt 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-encrypted-services.txt - Art. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Implement JSONP interface for check.torproject.org
On 2012-03-23, Arturo Filastò a...@baculo.org wrote: Since I noticed that check.tpo was removed from the front page I was thinking it would be a good idea to bring back up the topic of migrating check.torproject.org to a JSONP based system. JSONP gives the party which is expected to provide a piece of data the ability to run arbitrary JavaScript code in the security context of the website which requested the data. The Tor Project should never put itself in a position to have that level of control over other parties' websites. Such a system would also allow to have the JSONP check nodes distributed across multiple machines (avoiding the single point of failure that check currently is) and the client side software could be embedded inside of TBB directly. People could further promote the usage of Tor by placing an Anonymity badge on their website. A person wishing to setup such a node needs to simply install TorBel and a python based web app that runs this JSONP system. My threat model for this is very lax, so I don't see any purpose in bad actors telling a client when he is not using Tor that he is using it. If check.tpo tells the user is not using Tor it already means that TBB failed, the purpose of it is just to provide visual feedback to the user that all is did went well. check.torproject.org is the only service which can warn Tor users that a security upgrade is available for the Tor Browser Bundle. It is also accessed by every Tor Browser Bundle as the first page shown after the user uses the ‘New Identity’ Torbutton command; any party which can impersonate check.torproject.org can plant user-tracking cookies in every TBB user's browser. check.torproject.org cannot ever be run by untrusted parties, and cannot ever use a JSONP service provided by untrusted parties. If check is moved to git and you think it is a good idea I can start working on this. It is a more horrible idea now than it was the first time you proposed it. Robert Ransom ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Implement JSONP interface for check.torproject.org
On 3/23/12 4:34 PM, Robert Ransom wrote: On 2012-03-23, Arturo Filastò a...@baculo.org wrote: Since I noticed that check.tpo was removed from the front page I was thinking it would be a good idea to bring back up the topic of migrating check.torproject.org to a JSONP based system. JSONP gives the party which is expected to provide a piece of data the ability to run arbitrary JavaScript code in the security context of the website which requested the data. The Tor Project should never put itself in a position to have that level of control over other parties' websites. If this is a concern, and I don't think it is since Tor Project already has the ability to get users to run arbitrary code when they first start their browser, it could be managed by having the badge loaded on third party websites inside of an IFRAME. This would mean that the execution of anything is relative to that IFRAME. An alternative to using the JSONP object would be to do a XHR with Access-Control-Allow-Origin: *. This is only supported since firefox 3.5, but I don't think it would be an issue for TBB. A XHR does not lead to any code execution and all that the rogue node can do is tell the client that he is not running Tor. Such a system would also allow to have the JSONP check nodes distributed across multiple machines (avoiding the single point of failure that check currently is) and the client side software could be embedded inside of TBB directly. People could further promote the usage of Tor by placing an Anonymity badge on their website. A person wishing to setup such a node needs to simply install TorBel and a python based web app that runs this JSONP system. My threat model for this is very lax, so I don't see any purpose in bad actors telling a client when he is not using Tor that he is using it. If check.tpo tells the user is not using Tor it already means that TBB failed, the purpose of it is just to provide visual feedback to the user that all is did went well. check.torproject.org is the only service which can warn Tor users that a security upgrade is available for the Tor Browser Bundle. Good point. I had not considered this aspect. Though wouldn't this be replaced by thandy in the future? Are we sure the best way to inform users of updates is through check.tpo? It is also accessed by every Tor Browser Bundle as the first page shown after the user uses the ‘New Identity’ Torbutton command; any party which can impersonate check.torproject.org can plant user-tracking cookies in every TBB user's browser. With the XHR solution this would not be an issue anymore. check.torproject.org cannot ever be run by untrusted parties, and cannot ever use a JSONP service provided by untrusted parties. I disagree. If we properly define what the threat model is I am sure we can figure out a way to make a solution that fits it. The overall question is, currently check.tpo is a centralized single point of failure. Can we do better? Is there a way to run a distributed infrastructure of this kind? If check is moved to git and you think it is a good idea I can start working on this. It is a more horrible idea now than it was the first time you proposed it. Heh, I appreciate your comments, although you are often a bit rough :P. - Art. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
