October 2013 - tor-dev - lists.torproject.org

Pluggable Transport TBB Build
by Kevin P Dyer 09 Oct '13

09 Oct '13

Hi David, Sorry I missed the most recent Pluggable Transport bi-weekly meeting. In regards to the PTTBB build, I plan to make progress towards a streamlined build process. Platforms I want to get the PTTBB build working on: 1) CentOS 5.9 (32-bit) 2) CentOS 5.9 (64-bit) 3) Windows 7 4) OSX 10.8 For each build platform I'm going to: 1) Create a VirtualBox image. 2) Construct a script that takes the latest TBB release and VirtualBox image as input, and outputs a PTTBB zip file. The output PTTBB zip file will include all of the "deployed" pluggable transports. The build process must be deterministic and reproducible. I was hoping to do this on Amazon Web Services, to avoid the licensing issues. However, AWS does not support OSX. By using VirtualBox, it reduces the problem to each developer acquiring their own VirtualBox image for each target platform. Not desirable, but I don't have a better solution. I anticipate this will be a non-trivial effort to get working correctly. So, it would be great if you could help me adjust my plan to minimize headache! Thanks! -Kevin

2 4

Reminder: Attentive Otter IM Bundle Meeting in 1h
by Tom Lowenthal 09 Oct '13

09 Oct '13

Hello hello, This is your roughly 60-minute reminder that we'll be comparing proposals for the IM browser bundle on #tor-dev in about an hour. For your reference, and to brush up on the research that everyone valiantly did, the analyses are: *[Purple](https://lists.torproject.org/pipermail/tor-dev/2013-October/005544.html) *[xmpp-client](https://lists.torproject.org/pipermail/tor-dev/2013-October/005546.html) *[Instantbird](https://lists.torproject.org/pipermail/tor-dev/2013-October/005555.html) That's all for now. -Tom

4 3

Re: [tor-dev] [tor-commits] [tor/master] Clarify who learns about ContactInfo.
by Roger Dingledine 09 Oct '13

09 Oct '13

On Wed, Oct 09, 2013 at 01:45:26PM +0000, nickm(a)torproject.org wrote: > diff --git a/src/config/torrc.sample.in b/src/config/torrc.sample.in > index c667efc..78013c2 100644 > --- a/src/config/torrc.sample.in > +++ b/src/config/torrc.sample.in > @@ -120,9 +120,12 @@ > ## is per month) > #AccountingStart month 3 15:00 > > -## Contact info to be published in the directory, so we can contact you > -## if your relay is misconfigured or something else goes wrong. Google > -## indexes this, so spammers might also collect it. > +## Administrative contact information for this relay or bridge. This line > +## can be used to contact you if your relay or bridge is misconfigured or > +## something else goes wrong. Note that we archive and publish all > +## descriptors containing these lines and that Google indexes them, so > +## spammers might also collect them. You may want to obscure the fact that > +## it's an email address and/or generate a new address for this purpose. > #ContactInfo Random Person <nobody AT example dot com> > ## You might also include your PGP or GPG fingerprint if you have one: > #ContactInfo 0xFFFFFFFF Random Person <nobody AT example dot com> Hi Nick, Karsten, You've just changed the torrc.sample.in file, which will cause everybody who uses the deb and upgrades from Tor 0.2.4.17-rc to have to manually evaluate/adjust/replace their /etc/tor/torrc file. Are you sure you want to do this? It's not the end of the world here since the torrc.sample was last updated for Tor 0.2.4.3-alpha, so people upgrading from 0.2.3.x debs will already be affected. But I wonder if it's really worth hassling every deb user who will be upgrading from 0.2.4.x? In any case we should update the ## Last updated 12 September 2012 for Tor 0.2.4.3-alpha. line at the top of the file, so we can accurately predict who will be affected by changes like this in the future. --Roger

3 3

Attentive Otter: Analysis of xmpp-client
by Jurre van Bergen 09 Oct '13

09 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hoi, Below you can find the analysis of xmpp-client for the Attentive otter project, written by dgoulet, nickm, arlo, asn and myself. All the best, Jurre - -------- Intro xmpp-client is a simple XMPP client written in pure Go with OTRv2 support. It's a terminal program but doesn't have a GUI or a UI like GTK or ncurses. The software should be considered in an alpha state. *Is traffic send over Tor?* Yes, xmpp-client has support for sending all traffic over Tor, this includes connecting to onion's. When you connect to jabber.ccc.de or the riseup.net jabber service, you are automatically connected over Tor through their onion address (hidden service), if Tor is running. SRC lookups are not proxied. *Chat network(s) support* Only basic XMPP support, no extensions are implemented (XEP - http://xmpp.org/xmpp-protocols/xmpp-extensions/) *How trivial is extending XMPP-Client to different protocols?* This code base is only for XMPP and seems quite hardcoded for that. Section "Instant Messaging" - https://code.google.com/p/go-wiki/wiki/Projects#Networking * XMPP in Go - https://github.com/mattn/go-xmpp * IRC in Go - https://github.com/husio/go-irc * Various Go bindings - http://go-lang.cat-v.org/library-bindings *OTR* OTR support comes from the Go crypto package: https://code.google.com/p/go.crypto/ This library only has support for OTRv2 and not the latest OTRv3 specification. If we want to be resistant to several attacks[1] on the OTR protocol, we need to reimplement the OTR protocol and update it to the latest version or, we use Cgo, which binds into libotr. (Open questions: OTR by default?, ) [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.165.7945&rep=rep1&… *What languages are supported?* Currently, there is only support for English, extending the client with other languages is rather trivial like Farsi, French, Spanish and Arabic. *_Graphical interface_* A graphical interface needs to be implemented for the client. However, there is only a limited amount of graphical interfaces available, all are far from stable to use. The best bet for now is Go-GTKand extend it and let fixes go upstream. Another thing we could do is implement or extend an existing minimal implementation of a QT library. This means however, that we would need to maintain an extra "third party" UI library, which isn't Tor's core "business". * QT: https://github.com/visualfc/go-ui * GTK: http://mattn.github.io/go-gtk/ * Webkit: https://github.com/mattn/go-webkit *_Operating System Support_* *Windows* * MSI package support - http://golang.org/doc/install#windows *Mac OS X* * Package exists for Go - http://golang.org/doc/install#osx *Linux* Packaged in most distributions. *_Build & build automation_* *Cross-platform* Go compiles into a static binary. Next to that, Go has the possibility to build cross-platform binaries. *Deterministic builds* Some hacking needs to be involved and having a deterministic binary for Go might prove more difficult. I'm unsure whether this is going to be easily implemented (more research needed) *Browser extention* Of what I can understand with Xullauncher, we can start any type of applications shipped in the "TBB sandbox" in a specific path. With xmpp-client, it would require a Go version that is shipped with the TBB and every other library we use (i.e. crypto.otr). (Not 100% sure here...). A fat binary is an option here also (Go + otr + xmpp-client). *Control mechanism* A control mechanism needs to be implemented so xmpp-client can interact with Firefox in some way or the other. *_Hardening_* *Building with hardenend compiler flags* Hardening is possible by using gccgo, which is a frontend to the GCC gnu compiler. * http://golang.org/doc/install/gccgo *Sandboxing* * There is an existing AppArmor profile for xmpp-client for Ubuntu 11.04+ * There isn't a Seatbelt OSX sandbox profile. * There isn't a way to sandbox in windows. - -- Developer at https://www.useotrproject.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJSUu2kAAoJELc5KWfqgB0CnNAH/2ZpvUgB/enkgMZ7tH4q1cj7 w0S9N5bRD21JSYHpd9ZhvMOIHUOVOm8fothUvB1HVFwLhTMqsnqB5vtOPe117WYX WDp9rwicKz110r1dyEDcDhkGnI0OKJ5trDDalmmFaeFaP7gTwedee8lNRBdV+bPs tEqSGIxtNbY7WUpDZvTUBxkqZjAgWsag4K+fcn3ZA0m1vUmyWpyV+xYXCvjJH6fo oDVirvXpQibQxZWSLnRceq7otNXI1TdZL60KiipPJNDyfi5g5d3pToo3CU61wJgF 0KtvtzYnG5l476aJhd1hCdfO7Ni3NoZ1dheqPsRGcmNp/kICqbRYnc9MDqiCpEM= =e6xQ -----END PGP SIGNATURE-----

9 10

RESPONSE REQUESTED: scheduling Otter-related outreach, training, documentation &c. kickoff [due wednesday]
by Tom Lowenthal 08 Oct '13

08 Oct '13

People of Earth, heed my call! Based on feedback that Boisterous Otters has too much to do, and on the fact that current Boisterous meetings are using their full time on only half the topics, we're splitting Boisterous into two components. The first component is going to stick with the name Boisterous, and deals with the first two activities: the helpdesk, and l10n. If you're already working on these things, nothing is changing for you, and you may be able to stop reading this right here. The second component is picking up the name **Buoyant**, and will deal with the remaining activities: * written materials on general communications security * short videos multi-language training videos * outreach to Iranians and the Iranian diaspora * social-media, radio, and television outreach. * training, and train-the-trainer work If that sounds like your cup of tea, kettle of fish, or flagon of ale, then you should come help us get started by filling in this [Doodle][] **by Wednesday afternoon** so that I can plan a meeting at the end of this week or the beginning of next. Please fill out the Doodle if you're definitely coming, and plan to be part of the core effort. If you just want to show up to spectate or lend a hand, there's no RSVP needed. I plan to look at the Doodle around 1700-1900h Pacific tomorrow, and I'll use whatever it says then to try and pick the best time. I'll send the time out to tor-dev, bcc-ing everyone who's expressed an interest or answered the poll. That's 24 hours to give me your availability, but only about 16 hours between when I send out the time and the first possible meeting slot, so check your mail tomorrow evening Pacific. If you have any specific suggestions about venue, format, or other running *of the meeting*, and you plan to be there, please reply publicly or privately before I send out the scheduling meeting. If you have specific plans about how to git'er done, you can either email me, or bcc me on a tor-dev-bound email with an appropriately-ottery subject line. Do note, however, that other folks may not be able to read your suggestions if you send them less than 12 hours before the meeting. I'll try to read them anyway, but that's only out of the kindness of my heart. Questions on a postcard please, -Tom [Doodle]: http://doodle.com/pm5cfunbcwuyrwh6

1 0

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

Tor Beta area
by Phill Whiteside 08 Oct '13

08 Oct '13

Hi good people, I do run a relay [1], but with my work as Team Leader for lubuntu quality / testing [2] with our small, but dedicated, team I cannot allocate the time to install and test your RC. Instead, I put at your disposal a VM (kvm) with a dedicated ipV4 address running ubuntu server 12.04 LTS. This can be changed to what ever is best used for testing. I can take snapshots, so if you crash & burn it, it does not take too long to re-install. It also can pull full logs out out of a broken VM using guestfish[3] If this would be of use for you on alpha / beta testing relay software, please do get in touch. Regards, Phill. 1. https://metrics.torproject.org/relay-search.html?search=176.31.156.199 2. https://wiki.ubuntu.com/Lubuntu/Testing 3. http://irclogs.ubuntu.com/2013/06/28/%23ubuntu-classroom.html#t16:01 -- https://wiki.ubuntu.com/phillw

1 0

Fwd: [rt.torproject.org #14731] Off by one buffer overflow in tor stable
by Pedro Ribeiro 08 Oct '13

08 Oct '13

---------- Forwarded message ---------- From: Colin Childs via RT <help(a)rt.torproject.org> Date: 7 October 2013 14:25 Subject: [rt.torproject.org #14731] Off by one buffer overflow in tor stable To: pedrib(a)gmail.com On Mon Oct 07 12:13:21 2013, pedrib(a)gmail.com wrote: > Hi, > > I think there is a small buffer overflow (off by one) in the current stable > version of tor. > The function in question is format_helper_exit_status, which returns a > formatted hex string. It is in common/util.c, starting at line 3270. > The function has a comment header that explains how it works. It > specifically says it returns a string that is not null terminated, but > instead terminates with a newline. > > The code checks periodically throughout the function whether it has written > more bytes than it should. If it does, it errors out and writes a null > character in the current character positions. This by itself can lead to a > buffer overflow, but I believe the checks ensure that it almost never > writes over the buffer size - except in one case. > > After it has finished everything, it then checks again if there are more > than 0 bytes left in the buffer. If there are, it writes two characters - a > newline and a null terminator (lines 3342 to 3347). > > The problem here is if the buffer only has one byte left, an off by one > overflow occurs. These usually are very hard to exploit, but can be a > security issue nonetheless. > > However given that I am not familiar with the tor codebase I might be > wrong? I also did a quick security audit on the rest of the tor code and > couldn't find anything else. I was inspire because of the recent events... > > Regards > Pedro Hello, Please send a copy of this email to our tor-dev mailing list at https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev. Thank you! -- Colin C. ------------------------------------------- Hi, Please find above a bug report with possible security implications. I was a bit weary of sending to a public list at first, but I doubt the bug above is exploitable. Regards Pedro

2 2

REMINDER: Boisterous Otter helpdesk/l10n meeting in 2h, at 1200 Pacific
by Tom Lowenthal 08 Oct '13

08 Oct '13

Hello all, This is your irregularly-scheduled reminder that we will be discussing the Helpdesk and translation in just a smidge over two hours (that's 1200h pacific) in #tor-dev on irc.oftc.net. Highlights will include hearing from Sherief, Lunar, and Phoul about their research into ways to provide support chat accessible through our website. We'll also make a preliminary incursion into the topic of organizing shifts at predictable times. How very exciting! Other developments: I'm going to slice and dice Boisterous into two separate components which we'll run in parallel, otherwise these discussions and whatnot are going to run forever each. In this track, we'll continue with helpdesk and l10n. The other track will focus on outreach, training, videos, and documentation. If you're mainly in it for the helpdesk/l10n, you have nothing further to do: your meetings are just shorter. If you're interested in outreach, training, videos, and documentation, (and I already know that Kelley, Karen, Runa, and Sherief might be), then look for the meeting-scheduling message to go out to tor-dev, probably today. If you drop me a line, then I'll try to do something clever to make sure that the message hits your inbox too. That's all from this reminder. Any questions, folks? -Tom

1 0

CPAProxy - a thin Objective-C wrapper around Tor
by Claudiu-Vlad Ursache 08 Oct '13

08 Oct '13

Hi everyone, For those of you interested in making Tor available on iOS, I've recently released CPAProxy, a thin Objective-C wrapper around Tor ( https://github.com/ursachec/CPAProxy) The goal of the project is to release a free open-source browser on the AppStore that uses this wrapper and Tor to anonymize requests. It works by starting an instance of the Tor client in a background thread of an iOS app's main process. CPAProxy connects a socket to the client's control port, send an authenticate message and asks for the bootstrap progress until it reaches 100%. When the bootstrapping is done, the app is notified that Tor's SOCKS proxy is ready to be used. From that point on, networking requests can be sent over the proxy using Apple's iOS networking classes. The github repository contains two packet traces from a test app using CPAProxy of what traffic for an HTTP request looks like when it's sent over Tor and when in plain. The repo also contains build scripts that ease the compilation of openssl, libevent and Tor for iOS without changing anything in the "normal" build process except for removing _NSGetEnviron() and ptrace() calls in src/common/compat.c, since they're are not available on the iPhone. Each of the libraries are statically linked into the application binary. Before continuing with the endeavor of releasing a browser, it would help to know if there are people who think that it's not a totally bad idea to release software that uses Tor on a closed platform and to get some feedback on what security considerations are of high importance. Some open questions I'm still looking answers for: - What webkit features have to be disabled in order to keep anonymity intact while displaying web content? - Apple's networking classes provide ephemeral in-memory URL Sessions ( NSURLSessionConfiguration<https://developer.apple.com/library/ios/documentation/cocoa/Conceptual/URLL…>). Can those be trusted or should equivalent classes be written from scratch? - CPAProxy sets up Tor's DataDir in a temporary directory of an app's sandbox where it's not accessible by other processes. Should that directory be protected in any other way? - What is a good way of analyzing packet captures from an app using CPAProxy and Tor to see if any information leaks? If there's anyone with opinions on the project, it would really help to hear them. On #tor-dev I'm ursachec. All best from Hamburg, Claudiu -- Claudiu-Vlad Ursache Homepage: cvursache.com Phone number: +49 152 554 08 409 Address: Lange Reihe 113, 20099 Hamburg

2 1