- tor-dev - lists.torproject.org

[Draft Proposal] Scalable Hidden Services
by Matthew Finkel 07 Nov '13

07 Nov '13

Hi everyone, This is a proposal I wrote to implement scalable hidden services. It's by no means finished (there are some slight inconsistencies which I will be correcting later today or tomorrow) but I want to make it public in the meantime. I'm also working on some additional security measures that can be used, but those haven't been written yet. Many thanks to George for his initial feedback. I pushed this version to my public repo, and will continue to push updates there. In reality this is really 3.2 proposals, so the end result, if accepted, will look significantly different, but I'm indecisive at this point about which of the designs is least dangerous. Thanks, Matt

5 8

Re: [tor-dev] bananaphone obfsproxy module
by David Stainton 07 Nov '13

07 Nov '13

>> It wouldn't surprise me if the obfsproxy API is suboptimal or broken >> in some ways. If you find a problem, please let me know. I need a way for the BananaphoneTransport to build the markov model before the initial client connect... but right now it looks like __init__ is called upon connect. validate_external_mode_cli runs during setup before the connect... should I use that to set a BananaphoneTransport class variable to the markov model?

2 2

Please help me plan and run meetings in ways that you'll find most helpful
by Tom Lowenthal 07 Nov '13

07 Nov '13

Hi, my name is Tom, and I run meetings. There, I've said it. I've admitted it, and that's the first step on the road to recovery. We've been doing regular meetings for little over a month now, and I'd like to get some feedback and solicit suggestions, complaints, and ways to make the meetings suck the least they can. Please let me know what's working for you, what isn't working, and what should be better. In a slight departure from the norm, I'm even interested in non-constructive criticism: if something isn't working for you, but you don't know how to fix it, please still tell me so that I can try to come up with a way to mitigate it. Thanks for your feedback, -Tom

1 0

torsocks-v2.0.0-rc3 NetBSD improvements
by Thomas Klausner 06 Nov '13

06 Nov '13

Hi! I've patched torsocks-v2.0.0-rc3 to compile on NetBSD. There is one warning left: syscall.c: In function 'handle_mmap': syscall.c:88:9: warning: cast from pointer to integer of different size and I haven't done any functional tests yet. What is the easiest way to do that? Attached are the patches I've used to get this far. Some additional comments: The package installs a few files where it shouldn't: share/DEBUG share/SOCKS5 share/socks-extensions.txt These belong in share/doc/torsocks instead, I guess. And what is the point of src.old inside the tarball? Cheers, Thomas

3 3

Bug 9665
by Fábio Bertinatto 05 Nov '13

05 Nov '13

Hi, I would like to start contributing to Tor development thus I picked up a bug and tried to fix it. It's the 9665: https://trac.torproject.org/projects/tor/ticket/9665 I don't know whether I understood the problem well or not but I came up with the attached (trivial) solution. Could someone please check if it's ok? Thank you. -- F. Bertinatto

2 1

Re: [tor-dev] bananaphone obfsproxy module
by David Stainton 04 Nov '13

04 Nov '13

Howdy, Thanks. Your obfsproxy is a nice piece of work. Bananaphone + Obfs2 sounds cool! Modular transport chains make a lot of sense... I like modular transports... recently for fun I wrote a VPN in Python Twisted [https://github.com/david415/hushVPN] using twisted consumers and producers. My idea was to have a modular system where transports could easily be swapped. Over UDP it's very fast and I was thinking that maybe I could reuse some of that code to write packet transports for obfsproxy. For instance Tor over ICMP, DNS etc... Obfs2 over Bananaphone over UDP? Right now the david-bananaphone branch is functional code. I've tested it with ssh. SSH over Markov chains! It's laggy but it works. Leif's design plans are interesting... He will be better at explaining it. Perhaps it does something similar to your idea of RHE + Obfs2. Briefly: RHE(CRYPTO(HAMMERTIME(TOR))) - RHE is Banaphone's markov or random weighted Reverse Hash Encoding - CRYPTO is NaCl crypto_stream - Hammertime: "adds chaff to a bytestream to impede passive timing analysis" The goal is to not have any distinguishable patterns in the byte stream. Is that what Obfs2 accomplishes? We will do the crypto_stream secret key exchange using NaCl crypto_box and Elligator; spewing noise after keys are sent Elligator etc... We were thinking to first implement the key exchange without Elligator... and do that part later. I'm working on the basic key exchange to work in branch david-bananaphone-keyexchange https://github.com/david415/obfsproxy/tree/david-bananaphone-keyexchange I'm currently troubleshooting a problem with the message passing... Maybe I do not understand your api well enough... I'm getting strange behavior. It would help if another pair of eyes would look at this. Perhaps later I will formulate a question regarding the obfsproxy api... And I was hoping Leif would help me fix this branch: david-bananaphone-nacl-hammertime https://github.com/david415/obfsproxy/tree/david-bananaphone-nacl-hammertime I wrote a naclStreamEncoder coroutine and made hammertime_rh_server return coroutine chains with the NaCl stream encoders. It doesn't work at all... really a rough draft scribbling of code that makes the BananaPhoneBuffer unit tests through an exception... OK. I will add ALL commandline options to obfsproxy-bananaphone! OK... bandwidth overhead calculations... I'll take a look and run some tests. Onward! David On Tue, Oct 29, 2013 at 7:19 PM, George Kadianakis <desnacked(a)riseup.net> wrote: > Greetings, > > I'm the guy who develops obfsproxy. I recently noticed that you are > writing a bananaphone module for it. The code looks good and you even > understood the pretty-much undocumented obfsproxy API! Nice! > > BTW, I thought I should let you know that we are currently writing > software that combines transports together in chains. This means that > you don't have to worry about data redundancy in bananaphone, since > you can combine it with an obfuscating transport like obfs2 to create > the following chain: > tor data -> |obfs2 encoding| ->|bananaphone encoding| -> tor bridge -> |bananaphone decoding| ->|obfs2 decoding| -> tor data > This would create a bananaphone-encoded channel which transfers > obfs2'ed Tor data (so the bananaphone traffic will look uniform, since > obfs2 data is uniform (whether uniform bananaphone traffic is useful for > censorship circumvention is a different story))). > > FWIW, we are still in the process of writing this transport > combiner. You can read more about it in: > https://trac.torproject.org/projects/tor/ticket/7167 > https://trac.torproject.org/projects/tor/ticket/9744 > https://gitweb.torproject.org/pluggable-transports/obfs-flash.git > We should also create a Wiki page about it soon, I guess. > > Anyway, this transport combiner business means that you only have to > worry about making the bananaphone transport work. It would also be > nice if the transport was configurable, so that we can tweak its > parameters easily. I would also be interested in some bandwidth > overhead calculations :) > > BTW, feel free to send me any questions you have about obfsproxy or > pluggable transports. > > Cheers! > > PS: Feel free to CC the public tor-dev mailing list in your reply if > you want.

2 2

[RELEASE] Torsocks 2.0.0-rc3
by David Goulet 03 Nov '13

03 Nov '13

Hi everyone! I just pushed the 2.0.0-rc3 tag for the torsocks rewrite. https://github.com/dgoulet/torsocks/archive/v2.0.0-rc3.tar.gz Important fixes got in especially with the testing done with firefox lately. The good news is that it works well with firefox now :). Of course, you should ALWAYS use the TBB :). Support for x86 is also fixed as well as GNU/kFreeBSD and s390/s390x. Some unit tests were contributed by Luke Gallagher. Also, thanks to Lunar, there is now a Debian experimental package! http://packages.debian.org/experimental/torsocks There are several improvements on the way also that will make it probably in the 2.1.x version. * Optimistic data * Add --only-onions option Only sockify .onion address. Asked by the Tails folks. * Support .i2p address https://lists.torproject.org/pipermail/tor-dev/2013-November/005714.html * Maybe (hopefully), rename the whole thing with a more meaninful name. (Debate to come on tor-dev ML at some point in time :) * Basic UDP DNS support. Finally, to make this project go forward, please consider helping by reviewing and testing this code base. Here is the open ticket ref.: https://trac.torproject.org/projects/tor/ticket/10007 Here is the ChangeLog for 2.0.0-rc3. 2013-11-03 torsocks 2.0.0-rc3 * Fix: add fixtures directory to EXTRA_DIST * Fix: add fixtures.h to makefile.am as EXTRA_DIST * Fix: remove DBG call in syscall() * Fix: don't lookup symbol if already found * Lookup symbols in libc in constructor * Fix: bad ret value check for default logging * Add compatibility with GNU/kFreeBSD * Fix compatibility with s390 and s390x architectures * Fix: missing registry unlock on error * Fix: undefined syscall values for x86 * Fix: check fileno returned value * Fix: torsocks.in libdir path with lib prefix * Tests: add config-file tests * Tests: add utils unit tests Thanks everyone! David

1 0

Re: [tor-dev] .i2p address support in torsocks
by str4d 02 Nov '13

02 Nov '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/03/2013 06:58 AM, David Goulet wrote: > Apparently, I failed to put the person in CC :). I subscribed to tor-dev after talking with you :) > On 02 Nov (13:47:56), David Goulet wrote: >> On 02 Nov (19:25:42), Maxim Kammerer wrote: >>> On Sat, Nov 2, 2013 at 5:58 PM, David Goulet >>> <dgoulet(a)ev0ke.net> wrote: >>>> For now, it would only be .i2p address support (like .onion). >>>> In torsocks, it's not that difficult to support both >>>> addressing. >>> >>> Does I2P's SOCKS proxy work in a way that's similar to Tor? >>> Other proxies in I2P are protocol-specific — e.g., ports >>> 4444/4445 for HTTP(S) and 6668 for IRC. I am quite sure that >>> protocol-specific local I2P proxies like HTTP and IRC strip >>> sensitive information, so providing the user with an easy >>> access to .i2p services via SOCKS might be the wrong thing to >>> do. The SOCKS information page [1] is rather scarce on details >>> of what actually goes on inside the proxy, however. >> >> For now, it's simply detecting an .i2p address, opening a >> connection to the i2p daemon and pushing the request there. The >> person at i2p I talked to told me that it's quite straight >> forward and no special SOCKS5 mangling would be needed. Specifically, the I2P tunnel runs a local SOCKS server socket that handles the standard SOCKS4/4a and SOCKS5 protocols, and any data to be sent to the .i2p address is forwarded to an I2P socket. The standard (unfiltered) SOCKS client tunnel only forwards data between the SOCKS and I2P sockets, this should be functionally similar to Tor. We also have a variant that filters IRC traffic for anonymity (using SOCKS to connect to I2P IRC networks is a common use case), but this occurs during the forwarding step, the SOCKS server socket is unchanged. If a non-.i2p address is detected, the SOCKS server opens a SOCKS client connection to a configured SOCKS outproxy. This is designed to enable chaining to Tor, but it has some bugs that need fixing (this not working reliably is why I looked into torsocks). The configured SOCKS outproxy also needs to be listening inside I2P, which adds latency. If torsocks supported separate SOCKS ports for each configured .suffix, a user could run both I2P and Tor locally and use them in parallel instead of in series. >> If there is some work to do on the protocol side like you >> mention, I would imagine that the i2p daemon does it or else... >> well there is a problem :). If there are problems with our SOCKS implementation, they can be fixed (or implemented - I2P supports datagrams, but SOCKS UDP is not yet implemented). For filtering, it is up to the user to decide if they want to use a filtered SOCKSIRC tunnel or an unfiltered SOCKS tunnel, but it should not affect torsocks usage. (I want to make it possible for different filters to be written and used, but the user still needs to be made aware of the potential dangers to anonymity of generically SOCKSifying applications [1].) str4d >> >> Putting someone from i2p in CC: >> >> Cheers! David >> >>> >>> [1] http://www.i2p2.de/socks.html >>> >>> -- Maxim Kammerer Liberté Linux: http://dee.su/liberte >>> _______________________________________________ tor-dev mailing >>> list tor-dev(a)lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > >> _______________________________________________ tor-dev mailing >> list tor-dev(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBCgAGBQJSdXoiAAoJENXeOJaUpGWyBBMH/0c39pn97sBZvBj7HaMJAde2 ucn6Ug9vd41AmxNcOEhG65wpOrfB32sfnwI7DsRAYlOhjdxdquUl1yQHzTzs7NeG VLwRNe7e7Zv7VRj9uRp6t5+0YQU6++RkzhX5Jtn7l5W+3XYq0c4lRpSpwawP4NHN Zc9MveAU1tbsQqvhsFoYoJEsADpBj+97Xf0D05buUYMttjsmKv254HhGaLpuDCpv gEY3nBDHlHZqRziwxV7WmWPIsetdkATnmkUqcoCIPbZzJh2j6W3rZmHUieGU9OPC M3offV3ImZd/gSVcKW1rzDEEZh2mDcmg0XkwMbsEwc/LCn15y5jPk2yFlGpKKsE= =u2QY -----END PGP SIGNATURE-----

2 1

.i2p address support in torsocks
by David Goulet 02 Nov '13

02 Nov '13

Greetings everyone! I've been approached by I2P folks for adding ".i2p" address support in Torsocks. Since what torsocks does can be applied for both Tor and I2P, they felt that duplicating was not a good idea thus asking if merging both systems make sense and is possible. For now, it would only be .i2p address support (like .onion). In torsocks, it's not that difficult to support both addressing. I'm all for it, I don't see why it should not be done so I'm asking the community what do you think about that :). I can already see a question coming after this email being "Well there is "Tor" in torsocks". I'll keep that for an other thread because the whole naming of torsocks is on my todo list of things to discuss but before that I prefer getting the rewrite accepted. Thus, the naming is an "issue" but I want to address it later on (not only because of i2p). Cheers! David

6 8

two new proposals for bridgedb
by isis 02 Nov '13

02 Nov '13

I separated out the backend database improvements to BridgeDB from the social bridge distributor proposal. The former is finished and up for review and is being submitted to potential funders; the latter is still a draft (though now that some parts of the underlying crypto scheme and the threat model are detailed, early review is always helpful if anyone is super eager to point fingers at any mistakes I've made). Copies of both proposals are attached, and are also available in the common BridgeDB repo at https://gitweb.torproject.org/bridgedb.git/blob/refs/heads/feature/7520-soc… and https://gitweb.torproject.org/bridgedb.git/blob/refs/heads/feature/7520-soc… -- ♥Ⓐ isis agora lovecruft _________________________________________________________ GPG: 4096R/A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

1 0

two new proposals for bridgedb
by isis agora lovecruft 02 Nov '13

02 Nov '13

I separated out the backend database improvements to BridgeDB from the social bridge distributor proposal. The former is finished and up for review and is being submitted to potential funders; the latter is still a draft (though now that some parts of the underlying crypto scheme and the threat model are detailed, early review is always helpful if anyone is super eager to point fingers at any mistakes I've made). Copies of both proposals are attached, and are also available in the common BridgeDB repo at https://gitweb.torproject.org/bridgedb.git/blob/refs/heads/feature/7520-soc… and https://gitweb.torproject.org/bridgedb.git/blob/refs/heads/feature/7520-soc… -- ♥Ⓐ isis agora lovecruft _________________________________________________________ GPG: 4096R/A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

1 0

Project "Cute" - Design document and challenges - draft
by SiNA Rabbani 01 Nov '13

01 Nov '13

Dear Team, Sorry for multiple emails, I failed to send to tor-dev@ properly. Here is an attempt, a first attempt at the "Cute" project. Please let me have your comments and suggestions. https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter/Cute All the best, SiNA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ "Cute" design and challenges - draft 0.1 By: SiNA Rabbani - sina redteam io *Overview* Project Cute is part of the Otter contract. This project is to provide (in the parlance of our time) "point-click-publish" hidden services to support more effective documenting and analysis of information and evidence documenting of ongoing human rights violations and corresponding training and advocacy Our goal is to improve hidden services so that they're more awesome, and to create a packaged hidden-service blogging platform which is easy for users to run. *Objective* To make secure publishing available to activists who are not IT professionals. *Activities* Tor offers Hidden Services, the ability to host web sites in the Tor Network. Deploying hidden services successfully requires the ability to configure a server securely. Mistakes in setup can be used to unmask site admins and the location of the server. Automating this process will reduce user error. We have to write "point-click-publish" plugins that work with existing blogging and micro-blogging software. *Expected results* The result will be a way to provide portals to submit text, pictures, and video. These sites will not have the ability to log information that can be used to track down citizen journalists or other users, and will be resistant to distributed denial of service (DDoS) attacks. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ *Introduction* This document describes the technical risks associated with running a web-based blog tool and exposing it over a hidden service (.onion address). Our goal is to create a packaged blogging platform that is easy to operate for the non-technical user, while protecting the application from a set of known attacks that can reveal and compromise the network identity. Hidden-services make it possible for content providers and citizen journalists to offer web-applications such as blogs and websites, hosted completely behind a firewall (NAT Network) never revealing the public IP of such services. By design, Hidden Services are resilient to attacks such as traffic analysis and DDoS, therefore it becomes compelling for the adversary to focus on the application layer vulnerabilities. According to OWASP Top 10, Injection is the number one security risk for web applications. "Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker?s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization." [1] Running a site such as WordPress involves a LAMP (Linux, Apache, Mysql, PHP) installation. This stack needs to be carefully configured and implemented to meet the desired privacy and security requirements. However, default configuration files are not suitable for privacy and lead to the leakage of identity. WordPress is the most popular blog platform on the Internet. We select WordPress due to it's popular and active core development. WordPress features a plug-in architecture and a template system, "Plugins can extend WordPress to do almost anything you can imagine. In the directory you can find, download, rate, and comment on all the best plugins the WordPress community has to offer." http://wordpress.org/plugins/ Themes and plugins are mostly developed by programmers with little or no security in mind. New code is easily added to the site without the need for any programming skills. This is recipe for disaster, a quick look at the publicly available plugin repository and security forums reveals many of the OWASP top 10 vulnerabilities such as XSS and injection vulnerabilities: http://packetstormsecurity.com/search/?q=wordpress http://wordpress.org/plugins/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ *Adversary Model* We use the range of attacks available to the adversary adversary as the base for our Threat Model and proposed requirements. *Adversary Goals* *Code Injection* This is the most direct compromise that can take place; the ability for the adversary to execute code on the host machine is disastrous. *XSS the front-end, DoS the back-end* The adversary can overwhelm the database backed or the web-server of a dynamically hosted application, denying access to the service. *Location/Identity information* Applications that are not designed with privacy in mind tend to reveal information by default. For example, WordPress includes the name of the editor of a post inside the RSS feed: <dc:creator>John Smith</dc:creator> *Adversary Capabilities - Positioning* The adversary can position themselves at a number of places to execute their attacks. *Local Network/ISP/Upstream Provider* The attacker can hijack the DNS of the plugin repository or perform a man-in-the-middle attack and push malicious code into the blog. *Third party service providers* It is common for a blog to email authentication information. This information is at risk of social and legal attacks. The repository of the blog's source code where themes and plugins are downloaded is a target for the adversary to insert malicious code. *Adversary Capabilities - Attacks* The adversary can perform the following attacks in order to accomplish varies aspects of their goals. Most of these attacks are due to the dynamic and Web 2.0 nature of blog platforms. *SQL Injection & XSS* Dynamic sites take advantage of databases for content storage and JavaSript for client-side presentation. Programming mistakes can lead to code injection on server or client side. *Inserting plugins or core updates* Blog platforms have automatic update install features, WordPress connects to a remote repositories to download updated code. Adversary can perform a man-in-the-middle attack and insert malicious code. *Misbehaving plugins/features* Some plugins depend on remote connections to provide a feature, for e which can lead to leakage of identity. *Brute-force the admin password* Weak passwords are vulnerable to brute-force attacks. Blog engines do not provide protection against such attacks. *Remotely exploiting the LAMP stack* A determined adversary has a very large attack surface to analyze and discover 0-day vulnerabilities in Apache, PHP or Mysql applications. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ *Proposed requirement* *Dynamic to Static* A simple yet effective way to protect dynamic websites is to save a 100% static copy, hosted with a lightweight and well configured http server. We propose Nginx which is a free, open-source, high-performance HTTP server. We have the option of extending existing WordPress plugins such as "Really-Static" (HTTP://word press.or/plugins/really-static/) to generate 100% static files. *Disable Comments and New User signup (POST REQUESTS)* The ability to receive and store comments involves actions and configurations that expose the installation to DoS and other web attacks. We propose to completely disable reader's backed interactions, specifically disabling New User Registration and Comment features. *SOCKS Proxy support for WordPress* WordPress has the ability to proxy its outgoing connections, however the current implementation only supports HTTP proxy. We propose to submit a patch to WordPress core, enabling SOCKS Proxy support: http://core.trac.wordpress.org/browser/tags/3.6.1/wp-includes/class-http.php *Update safety* Tor Project or a partner such as WordPress.org should maintain the latest copy of the WordPress source-code over a .onion address. This will allow for the Core application updates to take place without ever leaving the Tor network and we achieve end-to-end encryption without relying on the traditional SSL/CA model. *OnionPress plugin* Instead of hard-coding our modifications to control WordPress' functionalities, we propose to develop a custom plugin. The plugin will provide a new menu in the Administrative panel of the site. Providing options to interact with Hidden Service features. (Note that Administrative features are going to be restricted from the public and only available to localhost) *User Authentication/Permission Levels* a) Blog Administrator This person is hosting the blog on a local computer and has physical access to the installation. There is only 1 of such role. This login will be restricted to localhost only. b) Blog editors/contributors These are the active content publishers. Each person has the ability to remotely connect, login and publish content. Editors do not have any administrative permissions such as adding or deleting users. Each editor is assigned a dedicated key and .onion hostname using the HidServAuth and HiddenServiceAuthorizeClient features in stealth mode. "HiddenServiceAuthorizeClient auth-type client-name,client-name,… If configured, the hidden service is accessible for authorized clients only. The auth-type can either be 'basic' for a general-purpose authorization protocol or 'stealth' for a less scalable protocol that also hides service activity from unauthorized clients. Only clients that are listed here are authorized to access the hidden service. Valid client names are 1 to 19 characters long and only use characters in A-Za-z0-9+-_ (no spaces). If this option is set, the hidden service is not accessible for clients without authorization any more. Generated authorization data can be found in the hostname file. Clients need to put this authorization data in their configuration file using HidServAuth." c) Readers (the world) These are the site visitors, they will be able to send GET requests to the .onion address and receive HTML and multimedia content. No login or comment posting permissions granted. *Packaged System* We propose to design and develop a Debian based Live OS that can be started as a Virtual Machine or to boot a personal computer. This OS will include Tor, LAMP stack and a running copy of WordPress. The LAMP installation will be hardened and configured to meet our security desires. We require a secondary USB disk for persistent storage. Desired outcome is a point-and-click and maybe portable solution that can be launched from inside of Windows, Linux or Mac OSX. VirtualBox is a second candidate to host the VM. http://wiki.qemu.org/Main_Page and/or https://www.virtualbox.org/ *Edge Cache Nodes* In order to provide "blazing-fast" access to the published content outside of the Tor network, we propose the deployment of caching servers operated by semi-trusted third party organizations or persons. These are similar to tor2web nodes:http://tor2web.or/ The content providers (bloggers) would select from a list of available edge servers and send a pgp signed zip file of the latest static version over Tor. Edge servers will reduce traffic from the Tor network, also provide a chance for content to reach the world in case of a DDoS or technical issues with the Tor network itself. Having cached copies available remotely make it possible for the blogger to get on-line, publish content and go back off-line, minimizing the amount of time and traffic spent on the Internet. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3 2

Proposal 221: Stop using CREATE_FAST
by Nick Mathewson 31 Oct '13

31 Oct '13

Filename: 221-stop-using-create-fast.txt Title: Stop using CREATE_FAST Authors: Nick Mathewson Created: 12 August 2013 Target: 0.2.5.x Status: Open 0. Summary I propose that in 0.2.5.x, Tor clients stop sending CREATE_FAST cells, and use CREATE or CREATE2 cells instead as appropriate. 1. Introduction The CREATE_FAST cell was created to avoid the performance hit of using the TAP handshake on a TLS session that already provided what TAP provided: authentication with RSA1024 and forward secrecy with DH1024. But thanks to the introduction of the ntor onionskin handshake in Tor 0.2.4.x, for nodes with older versions of OpenSSL, the TLS handshake strength lags behind with the strength of the onion handshake, and the arguments against CREATE no longer apply. Similarly, it's good to have an argument for circuit security that survives possible breakdowns in TLS. But when CREATE_FAST is in use, this is impossible: we can only argue forward-secrecy at the first hop of each circuit by assuming that TLS has succeeded. So let's simply stop sending CREATE_FAST cells. 2. Proposed design Currently, only clients will send CREATE_FAST, and only when they have FastFirstHopPK set to its default value, 1. I propose that we change "FastFirstHopPK" from a boolean to also allow a new default "auto" value that tells Tor to take a value from the consensus. I propose a new consensus parameter, "usecreatefast", default value taken to be 1. Once enough versions of Tor support this proposal, the authorities should set the value for "usecreatefast" to be 0. In the series after that (0.2.6.x?), the default value for "FastFirstHopPK" should be 0. (Note that CREATE_FAST must still be used in the case where a client has connected to a guard node or bridge without knowing any onion keys for it, and wants to fetch directory information from it.) 3. Alternative designs We might make some choices to preserve CREATE_FAST under some circumstances. For example, we could say that CREATE_FAST is okay if we have a TLS connection with a cipher, public key, and ephemeral key algorithm of a given strength. We might try to trust the TLS handshake for authentication but not forward secrecy, and come up with a first-hop handshake that did a simple curve25519 diffie-hellman. We might use CREATE_FAST only whenever ntor is not available. I'm rejecting all of the above for complexity reasons. We might just change the default for FastFirstHopPK to 1 in 0.2.5.x-alpha. It would make early users of that alpha easy for their guards to distinguish. 4. Performance considerations This will increase the CPU requirements on guard nodes; their cpuworkers would be more heavily loaded as 0.2.5.x is more adopted. I believe that, if guards upgrade to 0.2.4.x as 0.2.5.x is under development, the commensurate benefits of ntor will outweigh the problems here. This holds even more if we wind up with a better ntor implementation or replacement. 5. Considerations on client detection Right now, in a few places, Tor nodes assume that any connection on which they have received a CREATE_FAST cell is probably from a non-relay node, since relays never do that. Implementing this proposal would make that signal unreliable. We should do this proposal anyway. CREATE_FAST has never been a reliable signal, since "FastFirstHopPK 0" is easy enough to type, and the source code is easy enough to edit. Proposal 163 and its successors have better ideas here anyway.

3 4

Torsocks 2.x issue - Need eyes on that
by David Goulet 31 Oct '13

31 Oct '13

Hi everyone, I stumble upon an issue when testing torsocks[1] with firefox. I'm still wondering how this can be fixed thus I need more eyes on this :). The issue is that torsocks gets into a deadlock during the initialization phase within the libc. Here it is. This new torsocks version hijacks the "syscall" symbol (syscall(2)) in order to intercept applications that decides to do some network operations with that interface. To do that, the torsocks library constructor (executed before the application main()) lookup the original symbol in the libc (dlopen(3)) and is used for unhandled syscall values (for instance open(2)). Now the issue was detected with firefox which uses a custom malloc hook meaning that it handles its own memory allocation. This hook uses mmap() that firefox redefines to be a direct syscall(__NR_mmap, ...) and remember that this symbol is hijacked by torsocks. Torsocks constructor calls dlsym() to get the original libc syscall symbol. This call locks a "loading lock" inside the libc: dlfcn/dlsym.c +68: __rtld_lock_lock_recursive (GL(dl_load_lock)); Just after, dlerror_run is called which does a calloc() which then calls the firefox malloc hook and calls syscall() for mmap that torsocks hijacks. In torsocks, syscall() make a check on the original libc syscall pointer to see if it's NULL or not and if NULL, tries to look it up with dlsym(). And there you have the deadlock. dlsym --> LOCK --> dlerror_run --> calloc --> syscall() --> dlsym() --> dlerror_run --> DEADLOCK. It's a bit of a catch 22 because torsocks is basically looking for the libc syscall symbol but then it gets call inside that lookup code path... To be honest, I am not sure what's the right fix here or if there is any way to lookup the symbol in a "special" way that would help here. Any idea or questions are VERY welcome :). Hope this explanation is clear enough, this is a "not that trivial" issue. Cheers! David [1] https://github.com/dgoulet/torsocks.git

4 9

First draft of Requirements and Software Design for a Better Tor Performance Measurement Tool
by Karsten Loesing 30 Oct '13

30 Oct '13

Hi everyone, I just finished a first draft of a tech report sketching out the requirements and a software design for a new Torperf implementation. This is related to my earlier attempt to rewrite Torperf in Twisted [0], which I still think is a good idea, but only if somebody else who's better at Python and Twisted than I does it. Sathya offered help to implement this tool by "translating English into Python". But I think this project can keep more than one person busy for a while. I assume both Sathya and I would appreciate feedback from others. (Of course, I'm eager to hear your thoughts, Sathya.) Neither the requirements nor the software design are set in stone, and the implementation, well, does not exist yet. Plenty of options for giving feedback and helping out, and most parts don't even require specific experience with hacking on Tor. Just in case somebody's looking for an introductory Tor project to hack on. Here are the PDF and the LaTeX sources: https://people.torproject.org/~karsten/volatile/torperf2.pdf https://gitweb.torproject.org/user/karsten/tech-reports.git/tree/refs/heads… Feedback in the form of patches to the LaTeX sources is most preferred, though email replies are of course fine, too. Thanks! Karsten [0] https://lists.torproject.org/pipermail/tor-dev/2013-January/004356.html

4 6

One-Click-Publishing HS - aka "Project Cute"
by SiNA Rabbani 30 Oct '13

30 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dear List, I have been trying to help get Project Cute which is a "point-and-click" hidden service blogging tool, off the ground. So far I have 2 documents that have come out as a result of a few IRC chats. 1) Possible use-cases: https://trac.torproject.org/projects/tor/attachment/wiki/org/sponsors/Otter… 2) Working draft Design Document: https://trac.torproject.org/projects/tor/attachment/wiki/org/sponsors/Otter… Any comment or attention from you is very much appreciated. All the best, SiNA For the sake of discussion, I am pasting the Use Case document, so you can just reply away: This document is an attempt to list the possible users of a "one-click-publishing" hidden service. The goal of this effort, is to provide developers with a set of options and features that could support their development decisions. It is also an attempt to describe the challenges and risks associated with anonymous content publishing 1) Activist - a single person This is a person with a specific message or material. Wishes to share some content with the world, without revealing identity. This activist/publisher can operate from a range of private and public places. Such as: Work, Home, School, Internet Cafe and the public library. May or may not be able to dedicate a hardware for such activities. But we can assume access to to a computer that can be booted with a USB or CD. 2) Activists - 2 or more of them They all access the same site from different places on the Internet. They have specific political/social agenda. Often they maintain an AFK identity and an on-line persona. Hoping for a level of privacy. They each have different roles based on their skills. Roles like reporter, editor, graphic designer and comment-moderator. They publish content on a consistent bases, and very determined to get their words out. Such groups are the building blocks of large scale political/social movements. Their activities lead to mass protests and social change. 3) Whileslblowers This could be an employee of an evil entity that is about to do harm. For example company X bypassing international laws & selling DPI boxes to dictatorships. This whistle blower wishes to stay anonymous in fear of retribution. He/She may have limited technical abilities, and facing a well resourced adversary. 4) Professionals I call this group professionals because they usually operate like a business and involved in some sort of commercial activity. This group includes and not limited to: Newspapers, public and private entities. They wish to use the features such as end-to-end encryption and DDoS mitigation of hidden services, but don't have the desire or technical ability to setup a proper Hidden service. Many major newspapers are setting up whistle blowing portals on their websites already. 5) Anonymous Crime Reporters Police departments have webportals for the public to send "anonymous" crime reports. The reality is that these portals are NOT anonymous, considering the state of insecurities on the Internet. Such Law Enforcement groups can instead direct crime-reporters to launch a self hosted hidden service and not depend their lives on privacy by policy. 6) Anyone that does not or can not got to wordpress.com and register for a free blog. Help me identify these groreality ups :) - -- “Be the change that you wish to see in the world.” Mahatma Gandhi -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJScVN8XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGQ0E0NjQxNDg4RUMyMjUwOThBQzA0QTYz QzYyNzgwMTIyMkNFOUE4AAoJEDxieAEiLOmow2EP/iS+hA4QFq0d67DoWUaBffwd DAl4cYX94dxlYMjyvE6F1y9Gbj6FKfNXnerzUzCvsS+9SzQgHsPT2V2vbOItTI62 AfHm1EitUVO2YfdioJbUaom6Gh3JfIJukPjy0oJbbccK6jlQcs8TBFdas0FYi4ML YQNN/UQrGkSGm4JnnVCobFGwVBcVp7SOb3ClyGVTml/dpkntoHwyJ7aO6ZmoGhxv +bqx0o90cfka3a0wnamAhkTp1pUi1fMcDdG2OJ1ccemvaaBBmG/Gjt1Fw266HN2p 53vMZ6ZcEZE8iCGgShEm4nnq/FJn7mGuXHxwozjbYao5uCMPNrqCsfxnxS80H3d4 vH6ICCbF7ETfLoLVe//UV0+SRfnIaCQ97x8SMugnK1nKNlAvAuwvRZpm6xyteeoW syR2EfnNEERjmlzzqBlfjX9HkuSE0BAnWEbhTzsIzWyFjpr8KahYHtcTyKAyFcz1 ph6Wxi6/PAVNuAAow7gybKf425Qt19G85IU+3OZj6RtIl0vjnX1Umyu/3JvViLUs Y6gluA7RA6JMxH9a5p3BhjjnvEfIFFHGvwJeFf2wG3Tmq+N9XArS3kszFuvuW5j8 KaVWF7e2ql7BucgY9AasYkxobFOsX91THhOMaLJfqO9CtB3p2WxNQrsI64syd2SQ fr30v9bBRv0zN/bozpF7 =HEt2 -----END PGP SIGNATURE-----

1 0

Tech report: Evaluation of a libutp-based Tor Datagram Implementation
by Karsten Loesing 30 Oct '13

30 Oct '13

Hi tor devs, Steven, Rob, and I wrote a tech report on evaluating Steven's libutp Tor implementation in the public Tor network and using Chutney and Shadow: https://research.torproject.org/techreports/libutp-2013-10-30.pdf >From the introduction: """ Datagram designs are a promising approach to overcome Tor's performance-related problems. Advantages of datagram designs over stream designs are that they allow better end-to-end congestion management, reduce queue lengths on nodes, and prevent cell loss on one circuit delaying cells on other circuits. In earlier reports we compared possible Tor datagram designs and outlined a testing plan. In this report we evaluate our implementation of a libutp-based Tor datagram design. However, this evaluation does not focus on performance improvements over the current stream-based Tor implementation, because we found that our datagram-based Tor implementation is not mature enough for such a comparison. The focus is rather on our approach to integrate a datagram design into the Tor source code and on setting up test environments to evaluate the new design. We hope that our findings will be useful when further tweaking our libutp-based design or implementing other datagram designs. In the next section we describe our libutp-based Tor implementation in sufficient detail for others to understand our source code and to act as blueprint for implementing other datagram designs. Sections 3 to 5 outline the experimental setup that we used to evaluate our implementation and point out roadblocks that kept us busy longer than necessary. Section 6 concludes the report by sketching out possible next steps. """ As the introduction says, this report doesn't contain shiny performance comparisons, because we kept hitting bugs and then ran out of time. But the report contains detailed instructions for experimenting with libutp and Tor, and it has plenty of footnotes containing starting points and a conclusion with suggested next steps. In short, we had to stop when things started to be fun. Unfortunately, neither of us can work on this topic in the next two months at the very least. If anybody here wants to pick up this work and comes up with bug fixes or even a performance comparison to current Tor, please post your findings here! All the best, Karsten

1 0

[Otter/Buoyant] Tor Documentation Pad
by Colin C. 30 Oct '13

30 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello everyone, At today's Buoyant Otter meeting, it was determined that we needed a pad to organize our thoughts regarding the current documentation we have, and what we need. I have created a pad at https://zugzug.titanpad.com/3 for this purpose, and will begin adding resources to it tomorrow. - -- - -Phoul -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJScH3pAAoJEJ01Zvx7KO7Y1c0P/39cMM5fSdx5LIVdfuKVctYx 6hde6OPDvmTPzzTI03MlcYMKRSvH60cJUKCah2J7r2nfEGD3gw0uq0hcn/izc1wr +de7y3yAofbygFCT1k9v3KBaPi+nezvglqYu+hia9gsKuXf3+cLSATpymxTtUIDN eOtEIsggCjDv3eD8bs4rSYINI2B+j6V0qj5Lhts0nikbLkoiO/Q34RxELr1DQxot D+19Lvqb+yVCZE3NEsGyeJEu9hbAwRGgYgB2Qv/CSvbJ7c6SYFx4K0PUbG1ZYlHs wQ0MB6PoZ3cub4W4jb0R3HwyT++tBARvzbrbALHGehmKCNsY6wZ1ucx36xJB/p6x ABruNMjzAZhMPAz7yrf9cakOCskqXn10se21yd6EHUlknOKECEwzdCxJxE0Oswph OjISwL+JAkI5aTC52NGelIwd2VPrYY/2RkOgCnybop7wGsBBqNqrY7pGLiT03NJx m7MYE0RqJfZUjH++Ym52KU15ycPG2JhRxjnmym8OrvW1TPw0t24mSjfzIR0x90XI Og7teG9ugxv2rCftdCVMNKLUh8BVOTC7G6GIxeqPlii7IHiHEAqBdxAhXAm945WJ BjrimEQ0E73s/M/j7mDf7dblZegansvlHXuoBEpJSiT9fZHu3DAlAGvTS0dmBIkF aMUcspY2nbhD+zCdI4z2 =OVcv -----END PGP SIGNATURE-----

1 0

REMINDER: Buoyant Otter outreach, training, & documentation in an hour.
by Tom Lowenthal 29 Oct '13

29 Oct '13

Tor psyops group, We'll be meeting in #tor-dev in just under an hour to scheme, plan, and otherwise prepare out ongoing outreach, training, and documentation efforts. See y'all in an hour. -Tom

1 0

Why the limited HW engine algos in crypto.c?
by Joshua Datko 28 Oct '13

28 Oct '13

Why is there a limited set of OpenSSL engine algorithms chosen in crypto.c (code below)? log_engine("RSA", ENGINE_get_default_RSA()); log_engine("DH", ENGINE_get_default_DH()); log_engine("RAND", ENGINE_get_default_RAND()); log_engine("SHA1", ENGINE_get_digest_engine(NID_sha1)); log_engine("3DES", ENGINE_get_cipher_engine(NID_des_ede3_ecb)); log_engine("AES", ENGINE_get_cipher_engine(NID_aes_128_ecb)); Crypto hardware may be able to support various modes/key sizes and I would have thought one would want to support the algorithms allowed in TLS from the tor spec (MUST support SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA and SHOULD TLS_DHE_RSA_WITH_AES_128_CBC_SHA). Also, I was a bit surprised to see ECB mode. Is it true that ECB, when used as a stream generator, is equal to CTR mode? ECB mode is not mentioned in the spec and after some digging, I found a reference to it [1] for encrypting at most one block length of data in the header. To rephrase the opening question, it appears, by my limited review, that there is support for only a subset of the algorithms that Tor uses; what are the implications of increasing this support? Thanks, Josh [1] https://lists.torproject.org/pipermail/tor-commits/2012-July/044878.html p.s. My motivation for this question is that I'm trying to optimize the performance of the TI AM335X for use on the BeagleBone Black. While it can't compete with high end servers, it appears to hold its own behind a home network. Unfortunately, the processor doesn't support any asymmetric algorithms, which would help in circuit creation, but it does support various flavors of AES as well as SHA1.

2 2

Sponsor F: final Y3 meeting at 1100 Pacific today
by Tom Lowenthal 28 Oct '13

28 Oct '13

Happy Monday, This is your just-a-smidge-more-than-an-hour reminder that the final Sponsor F year 3 meeting will be in #tor-dev at 1100h Pacific. Bring true tales of your work, the final reports you've been preparing, and -- probably -- snacks. Sadly, I suspect that this meeting will last slightly more than the 90 assigned minutes. I plan to proceed in deliverable number order, so you may be able to use that as a gauge. If you can only be near the beginning or the end of the meeting, I'd love to know that forthwith so that I can jazz up the order for optimal conveniencing. Also, in the unlikely event that I still have your attention, it'd be really super neat if you could drop into the [Sponsor F year 4 riseup pad][1] and make sure that anything which sounds like you might want to help has your name near it, and that anything you might want to take point on has not just your name, but also as many time, difficulty, chance of success, and alternate result descriptions as you can. See y'all in an hour or so. -Tom 1: https://pad.riseup.net/p/Vt0TDXcdH0PB_Tor-Sponsor-F_Year-4 On 30 September 2013 19:13, Tom Lowenthal <me(a)tomlowenthal.com> wrote: > Today, at 1100 Pacific, we spent more than 90 minutes discussing > [Sponsor F][]. Here's the summary. > > **READ THIS**: The next Sponsor F meeting will be held in a mere two > weeks on **2013-10-14, at 1100h Pacific in #tor-dev**. > > This is a schedule change: from now on, the meetings will be every two > weeks. It's possible that we may have to increase this to every week, > depending on how fast we work, and how long meetings are taking. If > you should be at these meetings but cannot make Mondays at 1100h > Pacific, please contact me, and I'll start the process of finding a > better time or times. > > If you are individually in the `cc` field of this message, it's > because I think that there's something which I think you need to do > for Sponsor F before Halloween. You should also come to the next > Sponsor F meeting. If you can't make the meeting, or don't think this > work applies to you, you should get back to me ASAP so we can fix it. > > Is something else missing, wrong, or messed up? I'd like to know. > > [Sponsor F]: https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorF/Year3 > > > * * * * * > > > Core Phase 2 Deliverables > ========================= > > > UDP Transport [#10] > ------------- > > **[On Track: Minimal]** Karsten will work with Rob to complete the > Shadow simulation of this work, then write up a full report on this, > probably with Stephen's help. We expect both tasks to be complete by > Halloween. This likely represents a minimal outcome for this > deliverable. > > > Combine obfuscation (obfsproxy) with address-diversity (flashproxy) [#11] > ------------------------------------------------------------------- > > **[On Track: Minimal]** The work of integrating obfsproxy with > flashproxy is done. George will include this in the next released > version of the pluggable transports browser bundle. George will also > write a report on this work. Ximin and David will help. By Halloween, > the report will be complete and the bundles will either be released or > well on their way through testing. This likely represents some > combination of minimal or intended outcomes for this deliverable. > > > Bridge Metrics [#12] > -------------- > > **[Done: Intended]** Our reporting code has been merged into master. > It will ride the trains or flow downstream or whatever your favorite > code development cycle imagery is, and show up in future releases. As > it goes through alpha, beta, and release, gets picked up and adopted > by more operators, we'll get more comprehensive sample coverage, and > better data. This likely represents an ideal outcome for this > deliverable. > > > N23 Performance Work [#13] > -------------------- > > **[On Track: Alternate]** Roger doesn't think that N23 is as good as > we thought it was, so he's going to write a report on the various > performance improvements we've implemented lately; the performance > work which we though about, but decided not to implement, and why; and > a wishlist of future performance work and research. He'll have this > done by Halloween. This likely represents an alternate outcome for > this deliverable. > > > Improved Scheduling [#14] > ------------------- > > **[On Track: Intended]** Nick will work with Roger and Andrea to > implement an improved scheduler (possibly based on picking randomly, > weighted by bandwidth), and -- if possible -- also to refactor `cmux`. > If time permits, Nick will also attempt to simulate this using Shadow > , probably with Karsten's help. Finally, Nick will produce a full > report before Halloween. This likely represents an intended outcome > for this deliverable. > > > Alternate `Fast` Flag Allocation [#15] > -------------------------------- > > **[At Risk]** The person who we initially expected to do this work > does not seem to be available to do it. We need to find an alternate > plan to execute this deliverable. If you think you can do it, please > read [ticket #1854][#1854] and get in touch. > > [#1854]: https://trac.torproject.org/projects/tor/ticket/1854 > > > VoIP Support [#16] > ------------ > > **[On Track: alternate]** Our implementation strategy for this was > high-latency send-an-mp3-over-XMPP using Gibberbot/Chatsecure, or a > similar system. The internal milestone was to have a release candidate > available today. Sadly, Nathan (who is on point for this) wasn't on > the call. Fortunately, Nathan [blogged][guardian-1] about Chatsecure's > `12.4.0-beta4` ten days ago, and a tantalizingly-named > [`ChatSecure-v12.4.2-release.apk`][chatsecure-release] > ([sig][chatsecure-release-sig]) is available in the Guardian Project > [release directory][guardian-releases]. The outlook seems good, but > Tom will follow up with Nathan as soon as possible to verify these > outrageous claims. Nathan, if you're reading this, could you get in > touch (email, IRC, XMPP, whatever). Thanks! > > [guardian-1]: https://guardianproject.info/2013/09/20/gibberbots-chatsecure-makeover-almo… > [chatsecure-release]: > https://guardianproject.info/releases/ChatSecure-v12.4.0-beta4-release.apk > [chatsecure-release-sig]: > https://guardianproject.info/releases/ChatSecure-v12.4.0-beta4-release.apk.… > [guardian-releases]: https://guardianproject.info/releases/ > > > > Extended Phase 2 Deliverables > ============================= > > > VoIP Support [#17] > ------------ > > **[Limbo: Intended]** Here we're talking about getting a general VoIP > client (Mumble) to work over Tor. This discussed in [ticket > #5699][#5699], and [instructions][torify-mumble] for using Mumble over > Tor are on the wiki. We didn't get an update during the meeting, so if > you're working on this, get in touch, eh? > > [#5699]: https://trac.torproject.org/projects/tor/ticket/5699 > [torify-mumble]: > https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/Mumble > > > Simulating Tor [#18] > -------------- > > **[On Track: Intended]** Linus will finish Shadow improvements as > needed, and write a full report on his Shadow work. That'll all be > done by Halloween. This probably represents the intended outcome of > this deliverable. > > > Relays as Bridges [#19] > ----------------- > > **[Done: Minimal]** Using a public relay as a bridge works. > > > Defiance [#20, #21] > -------- > > **[At Risk]** We cannot work on these without open Defiance code. > > > Throttling Classifiers [#22] > ---------------------- > > **[On Track]** Adaptive throttling seems to come with unpleasant > anonymity tradeoffs, so we're not doing that right now. It looks like > static throttling will work really quite well, without these > tradeoffs. > > > Torbrowser Optimistic Data [#23] > -------------------------- > > **[Done: Ideal]** It's in your TBB *right now*. > > > > > FAQ > === > > **Q**: Why do you keep talking about Halloween? > **A**: We're currently in Phase Two of Year 3 of the Sponsor F > project. That phase ends on October 31st 2013, so we should try to > finish everything as best we can before then. Also: if we don't > finish, at midnight (local time) each person who has an outstanding > deliverable will be besieged by a seemingly-endless horde of zombies. > Others may be besieged too: the zombie report is hazy.

1 0

Retiring old user number estimates
by Karsten Loesing 28 Oct '13

28 Oct '13

Hi everyone, some of you may already know our new approach to estimating daily Tor users: https://metrics.torproject.org/users.html#userstats This new approach is in beta since April, and I'm quite happy with it. I trust the new numbers more than the old ones, both for direct users and bridge users. The new code for direct users is quite similar to the old one, but much cleaner. The approach for bridge users is a much better idea than the old hack. Today I added the missing features like the top-10 lists and the censorship detector. Why do I tell you this? Because the old approach uses resources on our poor, already overloaded metrics machine, and I'm planning to shut down the old approach in the very near future. Here's the plan: - Compute user numbers for 2012 and before; the current numbers start on January 1, 2013. This is going to take at least until September 23. - Take out the "BETA" labels and throw out everything above "New approach to estimating daily Tor users (BETA)". This could happen on October 1. Thoughts? Did I miss anything that's worth keeping? Anyone want to create an archive of their favorite graphs before I pull the plug? All the best, Karsten

5 15

Damian's Status Report - October 2013
by Damian Johnson 28 Oct '13

28 Oct '13

Hi all. Here's a quick update of what I was up to this October... ====================================================================== Stem Release 1.1.0 ====================================================================== After seven months of work Stem version 1.1.0 is finally out! https://blog.torproject.org/blog/stem-release-11 This month was primarily focused on pre-release performance and compatibility improvements in preparation for this... * Handful of improvements that reduced the memory usage of our Descriptor classes by 20%. [1] * Replaced Stem's custom caching with Python's @lru_cache. This was added to the standard library in Python 3.2, so Stem includes a Python 2.x backport to our utilities. [2][3] * Dozens of compatibility fixes for Python 2.6 and 3.x. * Added test coverage for Stem's interpretor examples, courtesy of Python's doctest module. [4][5] ====================================================================== GSoC Mentor Summit ====================================================================== Nick, Moritz and I attended the GSoC Mentor Summit at Google's main campus. By and large it was very similar to previous years, with many of the same faces and discussion topics. Unlike the prior couple years however I did not focus on keeping notes which, on reflection, was a mistake. Here's the small bit I remember... * Had a couple fun language discussions with developers from SciRuby and Scala. The former mostly concerned the advantages and disadvantages of Ruby with respect to Python (I use the former at work, so I've had some time to form an opinion on this). The later concerned Scala support for issuing database queries via list comprehensions. * Couple discussions with Wikimedia developers regarding Tor abuse. Unfortunately this is a perennial discussion that never seems to go anywhere despite having plenty of technical solutions. * Nick gave me a tour of Chutney's codebase and tried to persuade me to take on development of it. Nearly worked too. But while Chutney, SoaT, TorBEL, and a dozen other projects would be a lot of fun to work on I only have so much I can squeeze in alongside a full-time job. * A hackathon organizer with Random Hacks of Kindness discussed what they've found most successfully attracts contributors. The two most memorable tips were momentum and recognition. Regularly organizing events is necessary to maintain a core contributor group, and engaging local media doesn't hurt as it provides recognition for the contributors. * Shadowed Nick during discussions with a Mozilla developer concerning the upcoming Tor IM bundle. They certainly seem excited for OTR support... * Visited with Terry and Arc from the PSF quite a bit. Still no ETA on when distributions will switch to Python 3, and Mailman 3 is still a ways off. Momentum on lots of projects though. Evidently they acted as an umbrella org for roughly sixty students. I would weep bitter, bitter tears if I had to be the admin for that... ====================================================================== Other news this month includes... * Karsten, Andrew and I are now all moderators for the tor email lists. I'm taking point in this area, making daily sweeps through the moderator queue and tweaking Mailman to reduce friction. * Handful of DocTor fixes and improvements. Karsten shut down the Java DocTor early in the month so our shiny, new Python DocTor is now flying solo! * Attended events in the Seattle area including 'Go for Python Developers' at Google Fremont and the second TA3M meetup. * Worked with authority operators to resolve brief outages with dizum and urras. Cheers! -Damian

1 1

Using Stem to monitor TBB usage.
by remi py 27 Oct '13

27 Oct '13

Hy, I am having trouble using Stem to connect to the tor controller, while at the same time browsing the web using the TBB. The tor control settings can be edited in Vidalia -> settings -> advanced. There it is configured by default to use port 9150 and a random password for authentication, but I can not see what password. If I change any of these settings, then I cannot browse anymore, and TB displays "The proxy server is refusing connections". I am using this snippet: import stem from stem.control import Controller with Controller.from_port(port = 9151) as controller: controller.authenticate('') # provide the password here if you set one bytes_read = controller.get_info("traffic/read") bytes_written = controller.get_info("traffic/written") print "My Tor relay has read %s bytes and written %s." % (bytes_read, bytes_written) from https://stem.torproject.org/tutorials/the_little_relay_that_could.html So my problem is that I can not connect to the tor controller while at the same time browsing using the tbb. How do I fix this? Kind regards, Rémi.

3 3

This is my new OnionMail
by enfn 26 Oct '13

26 Oct '13

The first OnionMail server is working. OnionMail + Tails is simple!

2 1