tor-dev

tor-dev@lists.torproject.org

3581 discussions

[GSOC] Status report - Tor capabilities
by Cristian-Matei Toader 26 Jul '13

26 Jul '13

Hello tor-dev, For the last week I was on holiday for the graduation ceremony. I did however manage to get some work done, so for the past 2 weeks I have: - worked on adding parameter filters for the syscall filter; this is done using both a static list of parameters, as well as a dynamic list configurable at runtime; - parameter filters currently support numeric and pointer based parameters such as C strings; pointer based parameters are referenced in the original tor code through a getter (this was implemented for the 'open' syscall). - possibly identified a bug in libseccomp which was causing the accept4 syscall to fail to be added to the filter which was temporarily fixed by accepting all socketcall filters; still need to confirm this with nickm, but for those interested i believe -117 on this [1] line should be at least -120; my local fix makes everything work fine without socketcall. As a general conclusions things are going fine, I am currently trying to figure out what should go in the parameter filter. Another quick link to my remote branch for the ease of those interested: [2]. Looking forward to some feedback, if you happen to have any! References: [1] http://sourceforge.net/p/libseccomp/libseccomp/ci/release-2.1/tree/src/arch… [2] https://github.com/cristiantoader/tor-gsoc-capabilities/tree/gsoc-cap-stage2

1 0

[GSOC2013] EvilGenius status report
by Johannes Fürmann 26 Jul '13

26 Jul '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi *, In addition to attending the tor meeting in Garching (which was really awsesome, by the way) I really got some work on EvilGenius in the past two weeks. Since Arturo and I outlined the rough structure of the EvilGenius command line interface, I was gradually filling in the pieces needed for talking to the vagrant. Starting this tuesday, we built a set of unittests to test the functionality that is already in place. Since yesterday evening, after a bit of hacking, I already implemented the first and most difficult part of network plumbing and got the binary to create valid Vagrantfiles that are actually booting up the network they are supposed to. So, as Arturo said, "the Genius is there, all we have to do now is make it more evil.". We also might have to work on the plumbing a bit and fit some loose pieces together, which is what I shall be doing next week. By the way, it was really nice to meet all of you in Garching. Hope to see you all soon! Have a safe trip home and enjoy your weekend, everyone! Johannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR8m5qAAoJEAgie5o3Q/JpBzcQALiUslixPD5kIL0r+eNvXHU1 BDDDz9JUZhNc/4ZLa1AFXtY2GrJmB4wP6IOGjuj5rAPx0YcHUszVzjaTti5hWflr rlsXbbOgj4VWDsTAcO7AUbhrEVFaH/SlKgQesZKQuLTduDEhzXBSKga6VlCV37AF R//l8iXRBapwq5DzHSW4eYvNXorKF/nKN/ax7XYjZ5+X/P9sXZz1yHqk5/t187Lt mGbnrfcvEC5xkFpLgz/ReWZ7wABUMJRMrgTapI14rau94rGnaWSsVVjbNKRyYlr3 lhvgsEc6bmIRMhaBDn+Ujgt5o75Th3vJQ2T81wXIkWgrTEsZRZTAJGtyjO0nohtI G2UQmy+/U2Xam2tDyMh7xaGhNr4UN1NJpQ17TyCNPd4DzyO5XG6QjHhjb2s4U9ID YhflAo7yEj4P6NsRR+nIh5djveAgUF55sWNpp+fq1SK8VQ2UXMw6Pm76W7uwGIsw uf7icgTbSC7msSBXJf5HgyP7h3ZvlTrblP90/ciVuLS3YPUmwKYqfCJdnrP4PRYI 8p3bV9ZPU59a0Eqc8fhcQazXvaecUjzGfTpW2owkhQYtk2m7jDJ/Rzz6HbYpiToy 7P6N8T4dq9pp4Hb2ANARUPKYmcVYovYJtJZ9GD0zo5hWbi/i7sqPkJCO07RCyqg/ 5ePzmPqQorZP+nawhVbG =THS9 -----END PGP SIGNATURE-----

1 0

Comparing handshake protocols for Tor: Ace vs ntor
by Esfandiar Mohammadi 23 Jul '13

23 Jul '13

Hi, in WPES 2012 [2], Aniket Kate and me introduced Ace, an alternative for Tor's current handshake protocol ntor (which was also briefly discussed on this list [4]). Back then, no implementation for the double scalar multiplication operation (a * b + c * d) on Curve25519 was available. But recently, Robert Ransom implemented in his celator library [1] a highly efficient double scalar multiplication which is suitable for our handshake protocol Ace. In an internship with us, Shivanker Goel implemented and run comparative benchmarks of the Ace protocol, using Robert's celator library [1], and the current ntor implementation. Here are the benchmarks: 64-bit architecture: Ace: 401,129 cycles, ntor: 472,772 cycles, 32-bit architecture: Ace: 2,797,303 cycles, ntor: 5,179,069 cycles, About the benchmarks: * For cleaning the cache, the benchmarks runs the handshake 1000 times prior to starting the benchmarks. Then, we used a tsc_read() function to count the cycles, repeated the handshake 5000 times and computed the average of the cycles. * In order not to be forced to import too many functions from the Tor library, we do not use the function dimap_search, which looks up the secret key for a given public key, in the benchmarks. * We assume that ephemeral keys are precomputed, e.g., in idle cycles. In the benchmarks these ephemeral keys are received as an input. * For the benchmarks hyper-threading and overclocking were disabled and gcc-4.8 with "-O2" optimizations was used. The code is available online [2]. We also tried to formulate a tor-style proposal, which is also available online [3]. Any feedback, comments, or suggestions are welcome. - Esfandiar [1] http://www.infsec.cs.uni-saarland.de/~mohammadi/ace/celator.tar.gz [2] http://www.infsec.cs.uni-saarland.de/~mohammadi/ace/ace-benchmarks.tar.gz [3] http://www.infsec.cs.uni-saarland.de/~mohammadi/ace/ace-handshake.txt [4] It was discussed in the thread "Another key exchange algorithm for extending circuits: alternative to ntor?" from August 2012.

1 0

Remote descriptor fetching
by Damian Johnson 23 Jul '13

23 Jul '13

Hi Karsten. I'm starting to look into remote descriptor fetching, a capability of metrics-lib that stem presently lacks [1][2]. The spec says that mirrors provide zlib compressed data [3], and the DirectoryDownloader handles this via a InflaterInputStream [4]. So far, so good. By my read of the man pages this means that gzip or python's zlib module should be able to handle the decompression. However, I must be missing something... % wget http://128.31.0.34:9131/tor/server/all.z % file all.z all.z: data % gzip -d all.z gzip: all.z: not in gzip format % zcat all.z gzip: all.z: not in gzip format % python >>> import zlib >>> with open('all.z') as desc_file: ... print zlib.decompress(desc_file.read()) ... Traceback (most recent call last): File "<stdin>", line 2, in <module> zlib.error: Error -5 while decompressing data: incomplete or truncated stream Maybe a fresh set of eyes will spot something I'm obviously missing. Spotting anything? Speaking of remote descriptor fetching, any thought on the API? I'm thinking of a 'stem/descriptor/remote.py' module with... * get_directory_authorities() List of hardcoded (IP, DirPorts) tuples for tor's authorities. Ideally we'd have an integ test to notify us when our listing falls out of date. However, it looks like the controller interface doesn't surface this. Is there a nice method of determining the present authorities besides polling the authorities array of 'src/or/config.c' [5]? * fetch_directory_mirrors() Polls an authority for the present consensus and filters it down to relays with the V2Dir flag. It then uses this to populate a global directory mirror cached that's used when querying directory data. This can optionally be provided with a Controller instance or cached consensus file to use that instead of polling a authority. * get_directory_cache() Provides a list of our present directory mirrors. This is a list if (IP, DirPort) tuples. If fetch_directory_mirrors() hasn't yet been called this is the directory authorities. * query(descriptor_type, fingerprint = None, retires = 5) Picks a random relay from our directory mirror cache, and attempts to retrieve the given type of descriptor data. Arguments behave as follows... descriptor_type (str): Type of descriptor to be fetched. This is the same as our @type annotations [6]. This raises a ValueError if the descriptor type isn't available from directory mirrors. fingerprint (str, list): Optional argument for the relay or list of relays to fetch the descriptors for. This retrieves all relays if omitted. retries (int): Maximum number of times we'll attempt to retrieve the descriptors. We fail to another randomly selected directory mirror when unsuccessful. Our last attempt is always via a directory authority. If all attempts are unsuccessful we raise an IOError. ======================================== I'd imagine this would make use of the module something like the following... # Simple script to print all of the exits. from stem.descriptor import remote # Populates our directory mirror cache. This does more harm # here than good since we're only making a single request. # However, if this was a longer living script doing this would # relieve load from the authorities. remote.fetch_directory_mirrors() try: for desc in remote.query('server-descriptor 1.0'): if desc.exit_policy.is_exiting_allowed(): print "%s (%s)" % (desc.nickname, desc.fingerprint) except IOError, exc: print "Unable to query the server descriptors: %s" % exc ======================================== Thoughts? Does this cover all of the use cases we'll this module for? Cheers! -Damian [1] https://trac.torproject.org/8257 [2] https://gitweb.torproject.org/metrics-lib.git/blob/HEAD:/src/org/torproject… [3] https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l2626 [4] http://docs.oracle.com/javase/6/docs/api/java/util/zip/InflaterInputStream.… [5] https://gitweb.torproject.org/tor.git/blob/HEAD:/src/or/config.c#l780 [6] https://metrics.torproject.org/formats.html#descriptortypes

3 10

[GSoC '13] Tor status report - Searchable metrics archive
by Kostas Jakeliunas 22 Jul '13

22 Jul '13

Hey all, I apologize for this unusual timing for a status report, but I ended up delaying it beyond measure, so better now than later I guess. I can reiterate it + any updates soon, it's just that I figure I'm long overdue on informing tor-dev on what's going on. I've started my project [1] later than is usual, and more or less immediately ran into what I deemed to be a database / ORM scaling issue (the thing I'd been actually trying to avoid since writing the proposal), or at least a behaviour of the ORM which was suboptimal to what we have in mind: delivering (first and foremost) a searchable metrics archive backend/database which incorporates, as of current plan, server descriptors (relays and bridges, turns out a server descriptor model can happily service both) and server/router statuses across a few year timespan (currently using v3 consensus documents only), and provides querying functionality which can extract relations between the two. The 'querying with relations between the two' part, when tested on a broader span of data, seemed to be causing trouble to me. I ended up allocating probably inefficiently large amounts of time to this problem, rewriting the backend part, and trying to optimize the queries which underlied the ORM (turns out I didn't need to strip off the ORM abstraction - learned a few things about SQLAlchemy that way - I will follow-up with an email pointing to current code (sorry)). * The current iteration of the ORM model / backend (which actually is very simple) solves this problem. * Stem descriptor and network status mapping to ORM works, and is nicely (enough) integrated with the data import (from downloaded metrics archive) tools, as well as an API to make queries on the ORM. * Implemented a partial Onionoo-protocol-adhering (without compression and without some fields) backend for ?summary and ?details Onionoo queries. * Still tidying everything up. And *finally* writing a design document outlining what we actually ended up with, and what is required till full Onionoo integration. Code review will happen pretty soon, and hopefully we'll have some discussion upon where to go from here. Karsten mentioned that it might be possible to use the existing Onionoo incarnation to continue providing bandwidth weight etc. data (basically stuff from extra-info), and it might be possible to join the two systems into an Onionoo-supporting backend which will cover all / majority of archives available. Another (or) further avenue would be to continue with the initial proposed plan to extend the query format; and to build a frontend which would make use of the extended query format. Expect another email with links to (decent) code. [1]: http://kostas.mkj.lt/gsoc2013/gsoc2013.html

1 0

Problems. Flash plugin works by default! I can see youtube video with Tor Browser Bundle
by User of Tor 22 Jul '13

22 Jul '13

This was a HTML5 video. Thank you All for answers.

1 0

Problems. Flash plugin works by default! I can see youtube video with Tor Browser Bundle
by User of Tor 18 Jul '13

18 Jul '13

Hi, I've installed Tor Browser Bundle for Windows (tor-browser-2.3.25-2_ru) I didn't change any settings. When I visit any html-page on which there is a flash video i can see it, flash works! Why? It must not work! In settings(plugins) "Flash plugin" is disabled and it is inactive. In Tor Button settings Plugins are turned off. What happens? Is it a BUG? Regards.

5 4

TBB without Vidalia
by Zack Weinberg 15 Jul '13

15 Jul '13

How technically difficult would it be to remove Vidalia from an already-packaged TBB? (Ideally something that could be put into a shell script.) Basically what I want is a more-current-than-ESR10 browser that uses a system-installed & -configured Tor instance. I wouldn't miss the Torbutton UI, either (it should just use Tor all the time).

3 2

Status Report - Steganography browser addon a GSOC 2013 project
by Hareesan 14 Jul '13

14 Jul '13

Hi all, In last two weeks, I worked on detecting video and sound contents from web pages and get them as byte format to be used with algorithms later. To test it, use the test button in context menu over video element and it will alert the byte code of the content selected. ( Might take some time due to the video element file size). My next plan for coming weeks is to finish content uploading to extension from local memory. And more than context menus, all the content handling parts like toolbar button, menu buttons, upload options will be done by the end of coming two weeks. -- Hareesan

1 0

[GSOC] Status report - Tor capabilities
by Cristian-Matei Toader 13 Jul '13

13 Jul '13

Hello tor-dev, Here goes the status report for the past 2 weeks - I have been preparing the code for the first step of the project to be merged in the Tor master branch, which represented a number of changes required by nickm; the full process can be seen here [1], the branch was squashed and should be merged one of these days. - Step 2: - current progress - has changed a bit, and now requires to create a sandbox as 'tight' as possible around the Tor syscalls; - this is achieved my filtering not only syscalls but also syscall parameters, current efforts on my part can be found here [2] in branch "gsoc-cap-stage2"; - the current problem with this stage is filtering string parameters for syscalls which can be done using immutable strings using protected memory regions; - unfortunately some syscalls are out of reach being part of libraries and therefore their parameters cannot be controlled (the pointer used in the seccomp filter cannot be reference in the syscall) which will need to be solved (any suggestions are appreciated). - I have implemented ioerror's suggestion about policy files but is not pushed to git mainly because after talking to nickm we concluded that the implementation effort is not justified especially now when filter configurations are constantly changing which would require also changing how policy files are parsed, having mostly the same end result; furthermore some of the string filter parameters may be generated on runtime, which may be inconsistent with the solution, but I will keep this in mind towards the finishing stage of the development process, especially since it offers an elegant way of configuring and testing different filters. As a small side-note I will mostly be traveling the majority of next week, so I may not be as reachable as before. Looking forward to some feedback, if you happen to have any! References: [1] https://trac.torproject.org/projects/tor/ticket/9168 [2] https://github.com/cristiantoader/tor-gsoc-capabilities

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev