tor-dev September 2013

tor-dev@lists.torproject.org

59 participants
70 discussions

Torsocks tests
by Luke Gallagher 27 Jan '14

27 Jan '14

Hi, I would like to help with the unit tests for Torsocks, I was thinking of starting with utils and config-file tests, does this sound like a reasonable place to start? regards, Luke

2 8

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

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

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

Torperf implementation considerations (was: Torperf)
by Kevin Butler 23 Oct '13

23 Oct '13

[cc tor-dev] On 16 September 2013 09:47, Karsten Loesing <karsten(a)torproject.org> wrote: > Hmm, I don't think the HTTP client/server part is the right interface to > write another client and server and call it Torperf compatible. The > Torperf data API would be a better interface for that: people could > write their own experiments and provide data that is Torperf compatible, > or they could use the data that Torperf provides and analyze or > visualize it in a better way. But writing only half of an experiment, > client or server, wouldn't be of much use. > > I thought bit more about this and I don't fully agree (but you've nailed it that the data is the core api). I've come to the conclusion that I think it makes sense for TorPerf to do much of the heavy lifting and the core server aspects, but I think the experiments should be decoupled in such a way as to allow for flexible client implementations. Below are a bunch of semi related musings on how to get to this: Of course as many experiments will just be doing simple http requests, the experiments will really just be wrapper scripts around a bundled default client implementation which would be similar to the one in your perfd branch. Specifically, to aid in this, I'd propose something like the folder structure below: https://etherpad.mozilla.org/iqrgueVFd6 [Why a set of directories? There's not a solid reason other than it forces unique names and gives good opportunity to isolate experiment specific data. If an experiment has no specific data files it should be alright to just have the config file instead of a directory. A directory structure also mimics the idea of a restful web service as mentioned in the pdf, i.e. the user could easily know to go to http:/.../results/myexperiment/ to see results filtered for that single experiment. Either way, it's a minor detail, I just feel it's easier for a user.] A good use of the specific experiment data could be for static files, where anything in an experiments '/public' folder would be served by the webserver while that experiment is running. If wanting to ensure nothing gets proxy cached, the experiment could be responsible for generating random data files for each run. (This is a clear separation of server vs experiment implementation concern.) Another idea could be custom experiment views(js probably) that would transform the experiment results when viewed on the web dashboard. The experiments should not be responsible for determining details such as socks port or control port, the TorPerf service should deal with load balancing a bunch of tor instances on different ports and just tell an experiment 'Do your stuff using this sock port, this public ip:port, etc...' via environment variables. (The config could ask that certain aspects of the torrc file are setup specifically but managing ports and stuff is just asking for user error unless there's some experiment that requires it.) The config should minimally have an execution rate and a command. The command could be to just execute the bundled TorPerf client implementation with boring parameters e.g. just fetch facebook.com and record the normal timings that the default implementation tracks. A more interesting config's command could be the alexa_top_100 where it's just a basic script/makefile that fetches a new alexa list if the one in the local folder is older than X days and then for each site in the list it runs the TorPerf client instance. The TorPerf service instance should be able to run experiments by just executing the commands and recording whatever is written to stdout and stderr. After the command exits, if it's non zero then the stderr output is treated as error messages while if it's zero then it's treated as info messages. The stdout data should be treated as TorPerf results and it's an error if it's not well formed. If it's not well formed it should be captured in the results file for debug purposes. An example of informational output might be that the alexa_top_100 experiment updated it's list before this result set. [On the web interface it should be clear which results sets contained errors or information] Once the experiment finishes, the service should postprocess the results from the experiment and replace any fingerprinted entries (This needs to be well defined) with the server side timing information for that specific fingerprint. Then the server should store the results file in a timestamped file (timestamped probably by experiment start time) and update it's database(if there is one). The experiments should be able to specify their required tor version in their config, but it should accept placeholder values such as the default 'latest', 'latest-stable' or even 'latest(3)' which would run the experiment for all 3 of the latest tor versions. I think the ability to check the performance of the same experiment over multiple Tor versions could be interesting, especially to determine if any one build has caused anomalies in performance. I would expect very few experiments to run across multiple versions though. Additionally, something that could be neat, but it's not clearly in the requirements, should TorPerf be responsible for notifying the user when there are new clients available to run as latest? Would it be useful to be able to specify that some experiments should be run on 'master' or a gitref and that it would be pulled between runs? That's probably not practical. Apologies for the length and lack of order! Kevin

4 11

Status report - Stream-RTT
by ra 08 Oct '13

08 Oct '13

Hi all! During the last weeks I have been very busy working on my GSoC project which is about reducing the RTT of preemptively built circuits. There is now a single script called "rttprober"[0] that depends on a patched[1] Tor client running a certain configuration[2]. The goal is to measure RTTs of Tor circuits. It takes a few parameters as input: an authenticated Stem Tor controller for communication with the Tor client, the number of circuits to probe, the number of probes to be taken for each circuit and the number of circuits that should be probed concurrently. It outputs a tar file containing lzo-compressed serialized data with detailed node information, all circuit- and stream-events involved and the circuit build time for further analysis. Since the RTT-measurements are run in parallel with very short locks it is important not to overload Tor nodes. Therefore a single node is not probed more than once at a time. A first analysis of some measurements taken supports the original assumption that a Frechét distribution fits both the circuit build times[3] and round trip times[4]. I will continue gathering and analyzing measurement data and will hopefully be able to draw some conclusions from that. Best, Robert [0] https://bitbucket.org/ra_/tor- rtt/src/1127f6936086664981fc55b4dbc82b1570714140/rttprober.py?at=master [1] https://bitbucket.org/ra_/tor- rtt/src/1127f6936086664981fc55b4dbc82b1570714140/patches?at=master [2] https://bitbucket.org/ra_/tor- rtt/src/1127f6936086664981fc55b4dbc82b1570714140/torrc?at=master [3] http://postimg.org/image/je8k5yydt/ [4] http://postimg.org/image/ktk90vxm7/

3 9

RFC of proposal draft for "Migration to ed25519 HS identity keys and privacy-preserving directory documents"
by George Kadianakis 03 Oct '13

03 Oct '13

Here is another HS proposal draft. This one specifies how to migrate from the current HS protocol to the one specified in proposals "Migrate HS identity keys to Ed25519" and "Stop HS address enumeration by HSDirs": https://lists.torproject.org/pipermail/tor-dev/2013-August/005279.html https://lists.torproject.org/pipermail/tor-dev/2013-August/005280.html (I will soon write a proposal that merges these two proposals into one) This proposal is in serious need for comments. Specifically, see section "1.1. From the PoV of Hidden Services" which I left entirely unspecified. There are also probably multiple migration concerns which I have forgotten or completely ignored. Inlining: Filename: xxx-hs-id-keys-migration.txt Title: Migration to ed25519 HS identity keys and privacy-preserving directory documents Author: George Kadianakis Created: 13 September 2013 Target: 0.2.5.x Status: Draft [More draft than Guinness.] 0. Overview and motivation Proposal XXX introduces two new HS features: a) Stronger HS identity keys. b) New-style HS directory documents so that HS addresses are not leaked to HSDirs. This document specifies how different Tor actors must act after proposal XXX is implemented, so that the migration can proceed smoothly. We aim for the migration to be smooth both from the perspective of Hidden Services (introduce grace period so that HS operators don't wake up one day to find that their HS can't be accessed with that address anymore) and from an implementation perspective (avoid bloating the Tor protocol or introducing sensitive flag days). 1. Migration strategy After proposal XXX is implemented: a) The HS address format will change (called "new-style HS address" in this document) b) New HSDirs will be introduced (called "HSDirV3" in this document) c) New-style HS descriptors will be introduced (called "HS V3 descriptors" in this document). The following sections investigate how these changes influence the various Tor actors: 1.1. From the PoV of Hidden Services: === XXX DISCUSSION XXX === I see (at least) three migration strategies here. I'm not sure which one is better so I'll write all of them and we can then discuss them and pick one. a) After proposal XXX is implemented, Tor (configured as an HS) will only publish HS V3 descriptors by default. There will be a torrc parameter that the HS operator can use, that turns on publishing of HS V2 descriptors for backwards compatibility with the old HS address (the old identity key must be kept around). b) After proposal XXX is implemented, Tor (configured as an HS) will publish both V3 and V2 HS descriptors for each Hidden Service. There will be a torrc parameter that turns off publishing of V2 HS descriptors. This parameter will eventually be switched off by default. c) After proposal XXX is implemented, Tor (configured as an HS) will only publish V3 HS descriptors. The code that publishes V2 descriptors can be disabled or removed. HSes who want to publish V2 descriptors (and keep the same address) will have to maintain two copies of Tor -- one running the latest Tor version, and another one running an older version that supports V2 descriptors. The engineer inside me tells me to go with c), but I feel that it leaves all the burden to the HS operators. I haven't checked how much implementation effort doing a) or b) would take us. 1.2. From the PoV of the HS client: Tor clients can distinguish new-style HS addresses from old ones by their length. Legacy addresses are 16 base32 characters, while new ones are 56 (XXX) base32 characters. If Tor is asked to connect to a legacy address it SHOULD throw a warning and advocate the use of new-style addresses (it should still connect to the HS however). In the future, when old-style HS addresses are close to depletion, we can introduce a torrc parameter that blocks client connections to old-style HS addresses. 1.3. From the PoV of HS directories: Tor relays will advertise themselves as HSDirV3 servers using the "hidden-service-dir" router descriptor line. For a while, relays will also continue being HSDirV2 servers. We will specify a timeout period of X months (4?), after which relays will stop being HSDirV2 servers by default (using the HidServDirectoryV2 torrc parameter). 1.4. From the PoV of directory authorities: Authorities will continue voting for HSDirV2 servers. Eventually, when all relays have upgraded and no one is claiming to be HSDirV2, we can disable and remove the relevant code. XXX Need to specify grace periods. XXX What did I forget?

4 7

Criteria for prioritizing pluggable transport work
by Roger Dingledine 30 Sep '13

30 Sep '13

Below is my first go at a list of criteria to consider when evaluating pluggable transports for readiness of deployment to users. The goal isn't to say that every transport has to "pass" each question -- rather, I'm hoping to fund a researcher-developer at some point soon to polish some of the research prototypes so we can include them in the PT TBB, and I wanted to think about guidelines for how they should prioritize which PTs to work on. What points is it missing? What points does it mis-explain? See also George's "How the pluggable transports factory works" mail: https://lists.torproject.org/pipermail/tor-dev/2013-August/005231.html Thanks! --Roger ---- Section one, how reviewed / reviewable is it: 1) Is the software published, and is it entirely free and open source? Some designs call for non-free (and non-distributable) components like Skype, a copy of Windows in a VM image, etc. 2) Is there a published design document, including a threat model? Is there a specification? How testable are its security / unblockability claims? We should also consider how much peer review the design has received, and whether the project is getting continued attention by its inventors. 3) What is its deployment history? What kind of users did it have and how many? How much publicity? Did it get blocked? Section two, evaluation of design: 4) How difficult or expensive will it be to block the design (by protocol, by endpoints, etc)? For example, what services or protocols does it rely on being usable or reachable? Expense could include actual cost or could include collateral damage. Another way to measure might be the fraction of censoring countries where the technique is expected to work. 5) What anonymity improvements does the design provide, if any? While many pluggable transports focus only on reachability and leave anonymity properties to Tor, some research designs use the pluggable transport interface to experiment with improved traffic analysis resistance, such as by adding padding to defend better against website fingerprinting attacks. 6) What's the bandwidth overhead? Some transports like Obfsproxy don't inflate communication size, while others like Stegotorus wrap their communications in a more innocuous protocol at a cost of sending and receiving more bytes. Designs with higher bandwidth overhead can provide better blocking-resistance, but are also less suited for low-bandwidth environments. 7) Scanning-resistance: how does the design fare against active probing attacks, like China's follow-up connections that test for vanilla Tor traffic? ("How the Great Firewall of China is Blocking Tor", Philipp Winter, FOCI 2012). Section three, evaluation of implementation: 8) Does the implementation use Tor's Pluggable Transport (PT) Application Programming Interface (API) already? Tor has a standard recommended approach so transport modules can be invoked and managed by the Tor process. The PT API also allows Tor to automatically publish capabilities of the transport, collect user and usage statistics from the transport, and so on. 9) Is the implementation cross-platform (Windows, OS X, Linux at least)? How about support for mobile platforms? 10) How easy is the build process, and how easy is deployment and scaling? For example, what software libraries does it require, how likely are we to get enough bridge-side addresses, etc? 11) How is the code from a security and maintainability perspective? Are there unit tests, integration tests, etc? While the underlying Tor channel provides security properties like encryption and authentication, pluggable transports can still introduce new security risks if designed or built improperly.

1 0

Announcing liballium (A C Tor Pluggable Transports Utility Library)
by Yawning Angel 30 Sep '13

30 Sep '13

Hello, For those aspiring Pluggable Transports authors out there, I've recently written a simple library that handles the Tor Pluggable Transport Configuration protocol. The idea is for this library to be the C/C++ equivalent to pyptlib (and maybe more, depending on how much time I have to work on it). The code is available at: https://github.com/Yawning/liballium It still needs more documentation, but all of the use cases are covered by a reasonably well commented example (examples/ptcfg_example.c). Questions, comments, feedback all appreciated. -- Yawning Angel

1 0

HTTPS Server Impersonation
by Rohit 30 Sep '13

30 Sep '13

Hi, I was thinking about proposal #203 (Avoiding censorship by impersonating an HTTPS server) and have a few thoughts. I'm not sure if I've understood how everything fits correctly but here goes: For each bridge, we give their identity fingerprint and a shared secret along with their IP address and port. ie: bridge <ipaddress:port> <fingerprint> <shared_secret> The fingerprint allows the client to verify the identity of the bridge (via signed certificate) while a TLS connection is being set up. The shared secret allows the bridge to authorize clients after the TLS connection is set up. The shared secret could be sent using AUTHORIZE cells as proposed in #189 and #190. The AUTHORIZE cell could be wrapped in a HTTP GET request header. This should satisfy most goals. - A passive attacker wouldn't be able to distinguish between HTTPS->HTTPS traffic and Tor->Bridge. (Both use TLS) - An active attacker wouldn't be able to fool a client into thinking it was talking to a bridge. (Client would verify identity using fingerprint) - An active attacker wouldn't be able to fool a bridge into thinking it was a client. (No shared secret) To do the actual HTTPS impersonation, we could use Design #3 or #2 from #203. Nginx could be the reverse proxy, forwarding connections to the webserver or bridge as required. Depending on what the bridge is pretending to be, we could simply have nginx sitting in front of the bridge. I'm not sure what type of site the server should pretend to be. Some sort of blog? Maybe a login page? Or it could pretend to be a proxy service or perhaps web based ssh site? Could even be a combination of them I guess. Code changes would include - writing an nginx module to handle authentication - tor would need to handle AUTHORIZE/AUTHORIZED cell Thoughts? Did I miss anything? Thank you for your time, Rohit

4 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev September 2013