- tor-dev - lists.torproject.org

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

Trac Ticket 8291
by Bao Nguyen 27 Aug '13

27 Aug '13

Hi, I am one of the volunteer from Whonix project, a third party application. We want to use tor and modify it to parse the folder /etc/tor.d/ for configuration files. Please take a look at https://trac.torproject.org/projects/tor/ticket/8291 What is the process to get it approved and check in the file. I have modified the file src/or/config.c Who should I talk to? Thanks

3 4

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

26 Aug '13

Hello tor-dev, Apologies for submitting the report later than planned, but I was on holiday towards the end of last week. I am currently waiting for a code review for the stage 2 of the seccomp filter, which will very likely include a relatively long list of change requests. As a reminder, at the moment there should be one filter which does both syscall and parameter filtering. As a brief update the following changes were made for the past 2 weeks: - various syscall filter changes for linux 32/64 bit - dealt with issues related to the open syscall, due to the fact that we use path filtering and external dependencies happen to use 'open' with strings unprotected by the filter (libevent, getaddrinfo, openssl) - received feedback and added socket filters, which support parameter filtering only for 64 bits, since on 32 they get multiplexed on one syscall (socketcall) - waiting for review on [1] in public branch [2] For stage 3, further privileges will be dropped for different sections of code (eg. the worker threads), and the project will support multiple filters. More details may be found here [1]. Looking forward to some feedback, if you happen to have any! References: [1] https://trac.torproject.org/projects/tor/ticket/9249 [2] https://github.com/cristiantoader/tor -gsoc-capabilities/tree/gsoc-cap-stage2

1 0

Status report - Stream-RTT
by ra 26 Aug '13

26 Aug '13

Hello! Here goes my fourth status report on reducing the RTT of Tor circuits: I continued to evaluate lots of RTT-data of Tor circuits and drew some conclusions from that: *) The RTT measurements of circuits are subject to multiple influences and hence very diverse. *) There is no single distribution that fits them for all circuits. I am currently in the process of doing a demonstration of the improvement the active RTT probing yields. I delayed this report to provide some actual results but the demo is still half-baked.. Best, Robert

1 0