- tor-dev - lists.torproject.org

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

Damian's Status Report - September 2013
by Damian Johnson 29 Sep '13

29 Sep '13

Hi all. Present status: gobbling birthday carrot cake. Before that, though, did a few things worth noting in September... ====================================================================== Stem: Connection Resolution Support ====================================================================== Stem can now provide you with the active connections belonging to a process. This is similar to arm, capable of doing lookups via seven *nix and FreeBSD resolution methods... https://stem.torproject.org/api/util/connection.html#stem.util.connection.R… Unlike arm, however, this is a far cleaner implementation including both unit and integ tests. Unfortunately this doesn't yet work with Tor's DisableDebuggerAttachment feature, but I plan to look into workarounds for that soon. 'How do I use this', you ask? It's easy! https://stem.torproject.org/tutorials/east_of_the_sun.html#connection-resol… ====================================================================== Arm: Rewrote Starter Module ====================================================================== Arm is presently undergoing an overhaul, and this month I focused on its starter module. It's now shorter, has unit tests, and is just generally damn better... before: https://gitweb.torproject.org/arm.git/blob/refs/heads/release:/src/starter.… after: https://gitweb.torproject.org/arm.git/blob/HEAD:/arm/starter.py ====================================================================== Other news this month includes... * Google Summer of Code finals were last week. All the remaining students passed, having done great work - fingers crossed they stick around! * DocTor's python replacement is now happily chugging along on yatei and provides #tor-bots notifications. * Attended a local TA3M meetup hosted by Lee Fisher. I'll be presenting a 'tor ecosystem' talk at it in October. (https://www.seattleprivacy.org/?p=356) * Notified outdates relays that will soon be dropped from the network if they don't upgrade. (#9476) * Investigated tor regression reported by stem's jenkins tests. (#9746) * Code reviewed Aaron's TorPS. (https://github.com/torps/torps.git) * Fixed a stem caching bug regarding hidden service config options caught by wayzard. (#9792) * My site (https://www.atagar.com, which hosts arm) finally has SSL support. https://lists.torproject.org/pipermail/tor-commits/2013-September/062328.ht… Cheers! -Damian

1 0

File verification GUI tool
by Sherief Alaa 29 Sep '13

29 Sep '13

Hi Everyone, (moving this email from the support-team ML to tor-dev as Runa suggested.) I am starting to work on a small GUI tool for file verification because I find guiding users through the verification process on Windows/Mac through the command line painful. Tools in use: - Python 3.3 or 2.7 (still didn't decide yet). - PyQT - python-gnupg-0.3.5 I might also add a log window and a save log button to see what went wrong during the verification process. Attached is a draft design of how the tool would look like. On Mon, Sep 23, 2013 at 7:12 PM, Lunar <lunar(a)torproject.org> wrote: >How do you think users will be able to install such a tool on their >system? There won't be any installation required It's a single executable. >More importantly, how will they be able to ensure that it's >not a tampered version? I've thought about that and few things came to mind: - Include the executable inside TBB. - Host it somewhere and also provide a SHA-256 hash on a website or in a file. But this is all an endless chain because lets say I download TBB, then download gpg to verify it but then how do I make sure that gpg it self wasn't tampered with? (assuming I don't have it installed already.) Any help or suggestions would be much appreciated. Thanks. -- Sherief Alaa pgp 0x8623B882

6 6

Re: [tor-dev] Pluggable Transport Browser Bundle FTE Integration
by David Fifield 29 Sep '13

29 Sep '13

On Sun, Sep 01, 2013 at 01:32:23PM +0300, George Kadianakis wrote: > Kevin P Dyer <kpdyer(a)gmail.com> writes: > > === How do we invoke PTs? > > I had this discussion with Roger, but I don't see any open tickets or clear > > discussion on this already. If we have N>1 PTs and at least one bridge per > > PT, how do we select which PT (and which bridge associated with that PT) to > > use? Determinism is bad because then only one PT is used. Booting up all > > PTs is bad, especially if (say) the PTs make network connections prior to > > any incoming SOCKS connections. Selecting a random PT is potentially bad, > > too, depending upon how hostile and persistent and stateful the adversary > > is. > > That's an interesting question. I'm not sure if the process of Tor > picking bridges is deterministic or not. I should test it out. David > might know. > > (A good scenario would be that Tor treats bridges like guards and > selects some at random to build circuits.) I don't know how Tor decides which PT bridges to use. I would guess that it treats them like any other Bridge lines in torrc. You should see this ticket and blog post: "Config option to declare whether you're using bridges for reachability or for security" https://trac.torproject.org/projects/tor/ticket/4624 https://blog.torproject.org/blog/different-ways-use-bridge The idea behind it is that some users want covertness (I need to hide the fact that I am using Tor), and some users want reachability (I need some way to circumvent the firewall). The way I see it, the unstated policy of the PT bundles is to optimize for reachability. By default we launch all the transports we know about, so for example if three transports are blocked and one gets through, that is a success. This doesn't work for the first kind of user, for whom a blocked transport means they have been detected. This first kind of user is likely to have to take some extraordinary steps while using Tor in any case. I don't think we have a plan for how to make a bundle that, in its default configuration, is safe to use for all such users. However we can make a bundle that does reachability with no special configuration, so that's what we're doing. The new 3.0 series bundles ask you, on startup, whether you are able to connect directly to Tor or whether you have to do your own manual configuration (like adding bridges). The option to launch only one specific safe transport could in principle be added to such a UI. David Fifield

2 1

Help make the Tor stackexchange beta succeed
by Roger Dingledine 28 Sep '13

28 Sep '13

Hello Tor developers and anonymity researchers, Our Stackexchange beta is underway: http://area51.stackexchange.com/proposals/56447/tor and we could use some more participation from actual Tor developers, anonymity researchers, and so on. The goals include a) building a good set of answers to questions around Tor research and development, and b) growing a larger army of people who know these answers and can answer more such questions. If you can help out, please send me mail off-list, including what email address I should tell them for you, and I'll hook you up. Steven, Philipp, Jens, and I can't do it by ourselves. :) (And as a carrot, if you sign up you can read my answer to "What are the options to remove Mevade botnet from Tor?") Thanks! --Roger

1 0

New GPG key for Mike Perry
by Mike Perry 27 Sep '13

27 Sep '13

Hi everyone, I've finally made a new GPG key (after a scant 7 years!). This new key will be used to sign email from me going forward, and will be used to sign software releases until such time as I get around to creating a second set of keys on a hardware token for that purpose. While I dislike the Web of Trust for a number of reasons*, my plan is to cross-certify these two sets of new keys, and also sign both with my old key. Hence I will not immediately be issuing a revocation for my old key. The new key is attached, and is available on the keyservers (with a signature from my old key) at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x29846B3C683686CC Here's the fingerprint and current subkey information for reference: pub 8192R/29846B3C683686CC 2013-09-11 Key fingerprint = C963 C21D 6356 4E2B 10BB 335B 2984 6B3C 6836 86CC uid Mike Perry (Regular use key) <mikeperry(a)torproject.org> sub 4096R/717F1F130E3A92E4 2013-09-11 [expires: 2014-09-11] sub 4096R/A3BD8153BC40FFA0 2013-09-11 [expires: 2014-09-11] This message should also be signed by my previous key, which was used extensively to sign my email and my source code releases prior to today. * Ensuing flamewars about the Web of Trust should reply only to tor-talk. -- Mike Perry

1 0

[tahoe-dev] the GNU 30th Birthday party!
by Eugen Leitl 27 Sep '13

27 Sep '13

----- Forwarded message from Zooko O'Whielacronx <zookog(a)gmail.com> ----- Date: Fri, 27 Sep 2013 05:00:04 +0000 From: Zooko O'Whielacronx <zookog(a)gmail.com> To: tahoe-dev <tahoe-dev(a)tahoe-lafs.org> Subject: [tahoe-dev] the GNU 30th Birthday party! Folks: Tahoe-LAFS is one of the featured projects at the GNU 30th Birthday Party Hackathon! https://www.gnu.org/gnu30/celebration I'm going to be there in person in Cambridge. What I want to do during the Hackathon is make Tahoe-LAFS work better with Tor and/or I2P. I know that at least a couple of Tor developers and at least one I2P developer will be there in person, so this is a good opportunity to collaborate face-to-face or side-by-side. One thing I could spend Hackathon time on is just to contribute some patch review service to the Tor project, if it seems like they want that. Issue tickets relevant to this: Go to https://Tahoe-LAFS.org, click on "View Tickets" → https://tahoe-lafs.org/trac/tahoe-lafs/wiki/ViewTickets , click on "anonymity" → https://tahoe-lafs.org/trac/tahoe-lafs/query?status=!closed&keywords=~anony… Eyeballing those, I recognize the following as especially ripe, because the I2P folks have been working on them and flagging them as blockers for I2P: #68, #1010. https://tahoe-lafs.org/trac/tahoe-lafs/ticket/68# implement distributed introduction, remove Introducer as a single point of failure https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1010# use only 127.0.0.1 as local address See also a couple of patches that the I2P people are trying to contribute to foolscap, and which are also needed for full Tahoe-LAFS+I2P integration: http://foolscap.lothar.com/trac/query?status=!closed&keywords=~i2p You can join in! Just connect to us on IRC -- irc.freenode.net channel #tahoe-lafs -- or physically show up in Cambridge. Or, I suppose, at one of the other GNU 30th Birthday celebrations around the world: https://www.gnu.org/gnu30/ (scroll down to "Satellite Events"). ☺ Regards, Zooko _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Pluggable transport biweekly meeting - Friday Sept 27
by vmonmoonshine＠gmail.com 27 Sep '13

27 Sep '13

Hello PT devs, We'll have our next meeting (almost) today Friday - Sept 27 at CEST: 18:00 BST (Summer GMT): 17:00 UTC: 16:00 EST: 12:00 MNT: 10:00 PST: 9:00 @ #tor-dev on irc.oftc.net As last time asn is going to take us through this after identifying the participant we go one by one and update the group about our recent progress and blockers. As people suggested last time after update we will have a brief code review session when each of us will take at piece of code of another developer and comment on it. If you missed last the meeting or you need a bit of reminder you can find it summary here: https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/meeti… See you in few hours, Vmon

1 0