- tor-dev - lists.torproject.org

[RELEASE] Torsocks 2.0.0-rc2
by David Goulet 02 Sep '13

02 Sep '13

Greetings everyone! After a week or so, the release candidate 2 is now out after receiving various contributions for BSD and OS X support. A quick note. Please use the Github bug tracker for any issues and *not* trac.torproject.org. Until this code base is accepted as a potential replacement for the old version, please use the current repository issue tracker. Here is the ChangeLog: 2013-09-02 torsocks 2.0.0-rc2 * Fix: remove FAQ file from Makefile * Fix: remove out of date and inaccurate FAQ * Tests: add connection object unit test * Fix: Improve README file * Tests: add onion pool subsystem unit test * Use extern for tsocks_libc_* in torsocks.h * Define LIBC_SYSCALL_ for OS X * Make sure __darwin__ is defined * Fix: explicitly ignore fileno return value * Use AC_CHECK_FUNC rather than AC_LINK_IFELSE. * Find out if we really need libdl. * Define LIBC_SYSCALL_ for FreeBSD. * Use SYS_ from <sys/syscall.h>. * Include <sys/socket.h> for AF_INET*. * Use getsockname(2) for finding out socket address family Please continue to test, review and contribute it! :) Tarball: https://github.com/dgoulet/torsocks/archive/v2.0.0-rc2.tar.gz Big thanks to all contributors for that release! Cheers! David

1 0

Searchable metrics archive - Onionoo-like API available online for probing
by Kostas Jakeliunas 02 Sep '13

02 Sep '13

Hello, this accompanies my status report [1], and includes info how to query the searchable metrics archive for anyone curious. I also refer to the original (now semi-outdated) project proposal/document. [0] Only sending to tor-dev@for now. The Onionoo-like backend is listening on http://ts.mkj.lt:5555/ (backup URI where it's actually running (domain unrelated): ravinesmp.com:5555) This document details how it can be queried: https://github.com/wfn/torsearch/blob/master/docs/onionoo_api.md (It is, by design, an almost-subset (it does change some things as of now, though) of the Onionoo API [2].) Try not to DoS the thing, it is still fragile! :) (or, maybe do, but gently?) I will try to follow-up with a more detailed email, but this will have to do for now. Anyone curious should refer to the API doc. I'll soon add date range parameters, so it will become somewhat more useful. Examples: http://ts.mkj.lt:5555/details?search=mor http://ts.mkj.lt:5555/details?search=79. http://ts.mkj.lt:5555/statuses?lookup=9695DFC35FFEB861329B9F1AB04C46397020C… Please report any inconsistencies / errors / time-outs / anything that takes a few seconds or more to execute. I'm logging the queries (together with IP addresses for now - for shame!), so will be able to later correlate activity with database load, which will hopefully provide some realistic semi-benchmark-like data. [0]: http://kostas.mkj.lt/gsoc2013/gsoc2013.html [1]: https://lists.torproject.org/pipermail/tor-dev/2013-August/005310.html [2]: https://onionoo.torproject.org/ -- Kostas. 0x0e5dce45 @ pgp.mit.edu

2 3

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

02 Sep '13

On Sat, Aug 31, 2013 at 09:43:21PM -0400, Kevin P Dyer wrote: > === Building/Testing Tor on Linux/OSX/Windows > I'm trying to understand exactly how the current build/release process works > for tor. In regards to the PT TBB it seems like there are a few resources > [1,2,3]. However, is there a canonical documentation on how the release process > works? I'm especially interested in what you guys are doing to produce builds > on Windows. Are you using virtualization or do you have a few physical build > machines? > [1] https://gitweb.torproject.org/pluggable-transports/bundle.git > [2] https://lists.torproject.org/pipermail/tor-dev/2013-June/005056.html > [3] https://gitweb.torproject.org/builders/tor-browser-bundle.git There is fragmented documentation on how releases work. I have been building the PT bundles, but I have nothing to do with the building of the vanilla bundles from which the PT bundles are derived. The PT bundles are built by unzipping the vanilla bundles, copying some programs inside and modifying the torrc, and zipping the bundles back up. The PT build is mostly driven by this makefile: https://gitweb.torproject.org/pluggable-transports/bundle.git/blob/HEAD:/Ma… You should know that there are two varieties of the vanilla Tor Browser Bundle: the beta 2.0 series (e.g. https://blog.torproject.org/blog/new-tor-02416-rc-packages-and-updated-stab…) and the alpha 3.0 series (e.g. https://blog.torproject.org/blog/tor-browser-bundle-30alpha3-released) They differ much in their build process. We are using the 2.0 series to build the PT bundles, and there is no 3.0 version of the PT bundles. I would like to have the PT bundles built using the same deterministic process as is used for the 3.0 bundles (e.g. https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and…) See https://trac.torproject.org/projects/tor/ticket/9444 for the status of this project. Some further reading: https://trac.torproject.org/projects/tor/ticket/8019#comment:3 Much of the PT bundle build process is automated, but it still takes me two or three hours to boot VMs, download everything, verify signatures, build, sign, upload, and announce. I use VMs for the GNU/Linux and Windows builds. I use a physical Mac mini running OS X 10.8 for the Mac builds. (This is one reason I want to move the PT bundles to the 3.0 series--they cross-compile for all platforms and don't require a Windows VM or physical Mac.) The instructions for setting up the VMs and Mac are here: https://gitweb.torproject.org/pluggable-transports/bundle.git/blob/HEAD:/bu… https://gitweb.torproject.org/pluggable-transports/bundle.git/blob/HEAD:/bu… https://gitweb.torproject.org/pluggable-transports/bundle.git/blob/HEAD:/bu… > Prior to doing anything with FTE. I'd love to be able to create my own build > environment that produces that current obfs2+obfs3+flash_proxy bundles [6] > across all 4 OS/architecture configurations. > [6] https://www.torproject.org/docs/pluggable-transports.html.en Start with bundle-gnulinux.txt, as that's probably the easiest one. George told me that you have to use whatever the current Debian version number is rather than 7.0.0. It would help if you cna keep track of what parts of the instructions didn't work for you. David Fifield

1 0

Fraudulent PGP key with my email address (CEE1590D)
by Erinn Clark 02 Sep '13

02 Sep '13

Hello everyone, I discovered that there is a key out there (CEE1590D) associated with my Tor email address that is NOT me. I don't know who generated it, but I can think of many nefarious or incompetent reasons why they might have done it. This email is for two purposes: 1. To inform you that this is NOT MY KEY. Do not under any circumstances trust anything that may have ever been signed or encrypted with this key. I looked around and was unable to find anything, but nonetheless, it is out there and that is creepy. 2. If anyone on any of these lists has encountered this key anywhere -- the main fear being that it has been used to fraudulently sign packages of some kind -- can you please let me/us know ASAP? Tor Project official signatures are listed here: https://www.torproject.org/docs/signing-keys.html.en Consider that the canonical source for all signatures! Be suspicious of anything not listed there and let us know if you ever find anything. Thanks, The Real Erinn

2 1

Re: [tor-dev] Pluggable Transport Browser Bundle FTE Integration
by Kevin P Dyer 01 Sep '13

01 Sep '13

[Taking this discussion to tor-dev.] On Sun, Sep 1, 2013 at 6:32 AM, George Kadianakis <desnacked(a)riseup.net>wrote: > Kevin P Dyer <kpdyer(a)gmail.com> writes: > > > Hi George/David, > > > > Hi Kevin, > > > I spoke with Roger at USENIX. He said you're the pluggable transport (PT) > > gatekeepers. Please bear with me while I get up to speed. > > > > My goals: > > 1. I want Format-Transforming Encryption (FTE) [4] to be a "deployed" PT > in > > the PT TBB. > > 2. I want FTE to be integrated seamlessly with your existing deployment > > process. > > > > My initial roadblocks: > > > > === Building/Testing Tor on Linux/OSX/Windows > > I'm trying to understand exactly how the current build/release process > > works for tor. In regards to the PT TBB it seems like there are a few > > resources [1,2,3]. However, is there a canonical documentation on how the > > release process works? I'm especially interested in what you guys are > doing > > to produce builds on Windows. Are you using virtualization or do you > have a > > few physical build machines? > > > > Prior to doing anything with FTE. I'd love to be able to create my own > > build environment that produces that current obfs2+obfs3+flash_proxy > > bundles [6] across all 4 OS/architecture configurations. > > > > Building PTTBBs is mainly done by David these days. He has documented > his process here: > https://gitweb.torproject.org/pluggable-transports/bundle.git > (For example for Windows you would look here: > > https://gitweb.torproject.org/pluggable-transports/bundle.git/blob/HEAD:/bu… > ) > > The release process is not standarized. David is doing PTTBB releases > in a best-effort manner. > Right. On first glance, looks like this process will increase in complexity (and utilize more of David's time) as the number of PTs increases. I need to better understand the build process, then. > > === Implementing Managed Mode in FTE > > I've implemented preliminary functionality for "managed" mode in FTE. > > However, I think I'm confused about the role of managed mode. > > > > Say I add "Bridge fte IP:port" to torrc. Is "IP:port" supposed to be a > tor > > bridge, or a server-side PT service? If it's the former, then it seems > that > > the PT is completely responsible for managing a list of its own PT > servers. > > If it is the latter, I can't figure out how to dynamically determine, via > > the "managed" environmental variables, how to capture user-entered > > "IP:port" information in Vidalia. > > > > It is the latter. <IP:port> points to the server-side PT service. It > does *not* point to the ORPort of the bridge (we don't care about it). > > > Concretely, if I have "Bridge fte IP1:port" and ""Bridge fte IP2:port" in > > my torrc, how does "IP1:port" and "IP2:port" get propagated to my PT via > > the managed interface? > > > > The <IP:port> is *not* passed to your transport using the managed > mode. Instead, <IP:port> is passed to your transport using the SOCKS > protocol. That is, when Tor wants to connect to the bridge, it does a > SOCKS handshake to your transport, and asks your transport to connect > to <IP:port>. Is this documented anywhere? > > === 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.) We should definitely try to flesh this out. > > We should probably chat about this. (Maybe you already have and I'm out > of > > the loop?) It is especially important as the number of PTs increases. > > > > I'm happy to take this discussion (or a subset of it) public, if you > think > > it'll help others. I just didn't want to spam tor-dev/tor-assistants with > > this initial email. > > > > Yes, let's take it public. > Feel free to CC tor-dev in your next reply. > Done. > BTW, on the topic of deploying your PT, have you seen: > https://lists.torproject.org/pipermail/tor-dev/2013-August/005231.html ? > > FTE seems to be missing out on the code quality front. > The Python code is quite complex and undocumented. There is also some > C++ code in the codebase that is also complex and undocumented. We > have decided that we won't ship C/C++ code in PTs, except if it's dead > easy to review or if it has gotten heavily scrutinized. Any chance > that the C++ code could be written in a memory-safe language? Roughly, FTE has an offline mode (building DFAs, needs to be done once) and an online mode (transporting data, deployed to everyone.) In terms of C++ code, there are ~300 line of C++ code used in online mode that were implemented for performance-critical algorithms. Implementing this code in Python will slow FTE down by at least an order of magnitude. I'll document why I made this decision. Alternatively, any suggestions for a memory-safe language that allows hooks for Python and affords the same performance as C++? In terms of reducing complexity of the Python code, and increasing code documentation, do you have concrete suggestions? It would be great if you could raise a few issues on FTE's github [7]. My time is limited and I would prefer to focus on the things you care about. Thanks, Kevin > [1] https://gitweb.torproject.org/pluggable-transports/bundle.git > > [2] https://lists.torproject.org/pipermail/tor-dev/2013-June/005056.html > > [3] https://gitweb.torproject.org/builders/tor-browser-bundle.git > > [4] https://kpdyer.com/fte/ > > [5] > > > https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/180-pluggabl… > > [6] https://www.torproject.org/docs/pluggable-transports.html.en > [7] https://github.com/redjack/FTE

1 0

Trac upgraded to 0.12.3
by Erinn Clark 01 Sep '13

01 Sep '13

Hello everyone! Weasel and I have upgraded https://trac.torproject.org to a newer version. Right now it has all of the functionality you were already accustomed to, but in the next few days it will get some more exciting features, like git integration. (I already verified that we are able to do it with our current git setup, but I will need to go through and poke at individual repos to make sure it works correctly.) Right now I'm just starting with a small list: arm, tor-browser-bundle, obfsproxy, stem, tor, torbrowser, and torbutton. (I tried bridgedb but trac freaks out because it doesn't like something about that repo; I will try to figure out what's wrong after I finish these others). If you want git integration for your repo(s), please file a ticket against the Trac component and I'll see what I can do! Once the git integration works, we'll demo a code review tool (http://trac-hacks.org/wiki/CodeReviewerPlugin) I'll email again once we're further along with both of these processes. In the meanwhile, let me know if you run into any issues with the new trac. Also, I would be remiss if I did not mention Mike's new favorite feature: a tag cloud. https://trac.torproject.org/projects/tor/tags Thanks, Erinn (& weasel)

2 2

Tor Control PHP library
by Kévin Dunglas 30 Aug '13

30 Aug '13

Hi, I've built a PHP library implementing the TOR control protocol: https://github.com/dunglas/php-torcontrol/ I've also built a Symfony framework bundle for this library: https://github.com/dunglas/DunglasTorControlBundle It allows to control a Tor server from a PHP script. Of course it's open source (MIT license). Can you add this library to the list ? -- Kévin Dunglas Freelancer http://dunglas.fr

2 2

Torsocks 2.0.0-rc1 release
by David Goulet 29 Aug '13

29 Aug '13

Greetings everyone! Two months ago I sent an email [1] to the tor-dev mailing list explaining some important issues with torsocks. I proposed myself to do a complete rewrite for the reasons detailed in the email. I've released today the first release candidate for a 2.0.0 version. https://github.com/dgoulet/torsocks Package: https://github.com/dgoulet/torsocks/archive/v2.0.0-rc1.tar.gz I'm asking the community for feedbacks, testing, code review, optimization design and/or anything useful to help improve the project (even correcting the mistakes or improving any comments). The TODO file in the repository contains some needed features but that are not critical to the project for a beta release. Hopefully, with your help, we will be able to replace the current version with a better one, more tested, more hardened and more portable!... and maybe with a more meaningful name :). What is really needed right now is OS X and BSD testers. I did my best to only use POSIX standard and making sure that libc calls are the same on all platforms but I was not able to test it on other OS other than Linux so they might some issues. There is *no* Windows support but again that would be amazing if someone could port it. Again, please contribute and help this very useful tool getting better! I encourage you all to use tor-dev mailing list for any development issues. I'm also on IRC in #tor-dev as "dgoulet". You can also find me on OFTC, freenode and indymedia servers. Big thanks to everyone! Using it is testing it! :) Cheers! David [1] https://lists.torproject.org/pipermail/tor-dev/2013-June/004959.html

4 7

Trac Ticket 1922
by Bao Nguyen 28 Aug '13

28 Aug '13

Providing a fix for #1922, I urge whoever has the authority to decide what folder tor is to parse. I saw /etc/torrc.d/ and /etc/tor.d/ or any others. I am going to make a patch. So which one is it?

1 0

HSDir hash ring modification
by Kang 28 Aug '13

28 Aug '13

Hello. I was reading about hidden services and a thought occurred to me regarding the hash ring used in choosing and determining the HSDirs for a hidden service. As far as I can tell the hash ring is more or less static since a relay's position is determined by their identity key, which doesn't change. I'm also under the impression that the hash ring is only used for calculation of HSDirs of hidden services. I don't have a particular method in mind, but it seems to me that you could use the "time-period" value that is used in calculation of the service's descriptor-id to shuffle the ring. This would cause the ring to be different for each hidden service, and also make its order change periodically. I imagine in particular it would make onion address enumeration attacks more difficult, since an attacker wouldn't just be able to "cast a net" over the ring for all services. Can anybody see any problems or false assumptions with this? Thanks

2 3