- tor-dev - lists.torproject.org

Attentive Otter: Analysis of Instantbird/Thunderbird
by Mike Perry 09 Oct '13

09 Oct '13

This outline was a collaborative effort between me and Sukhbir Singh. Code and package URLs: Packages: http://instantbird.com/download-all.html Nightlies: http://nightly.instantbird.im/ Instantbird Code: http://hg.instantbird.org Thunderbird Code: https://github.com/mozilla/releases-comm-central FAQ: http://instantbird.com/faq.html Instantbird Overview: + Cross-platform (Windows, OS X, Linux). + Based on XUL+XPCOM (specifically Thunderbird). + Many existing Thunderbird addons should be easy to port. + Periodically syncs its codebase with Thunderbird: - https://bugzilla.mozilla.org/show_bug.cgi?id=920801 + Thunderbird can be used as combined secure Chat+Email communications software. + One piece of software for all secure communications is a usability win + Leveraging the work done on TorBirdy, we can distribute Instantbird and Tor (and related components) in a single package, or as a combined addon. + Use Tor Launcher as the controller (sukhe recently added Thunderbird support) + Will allow seamless zero-configuration Tor usage for normal case, and will share Tor Browser's future Pluggable Transport support with no additional effort. + See the TorBirdy manual for more information: https://trac.torproject.org/projects/tor/wiki/torbirdy#TorBirdywithTorandTo… + Good protocol support: Currently Instantbird supports by default: AIM, Bonjour, Facebook Chat, Gadu-Gadu, Google Talk, Groupwise, ICQ, IRC, MSN, MySpaceIM, Netsoul, Odnoklassniki, QQ, Simple, Twitter, VKontakte, XMPP, Yahoo and Yahoo JAPAN. + Supports "portable version". + InstantBird is available in 14 languages; Thunderbird is available in ~65 + Clean and easy to use interface. + We are amassing a fair amount of in-house expertise with Mozilla/XPCOM, which we can use for code review, UI design, etc. + Can also leverage our existing relationship with Mozilla to share workload Security Properties: * Currently based on libpurple, but Mozilla is working to replace libpurple with pure JS implementations (due to both licensing and code quality/security issues with libpurple). Instantbird nightlies have this code but it must be enabled via about:config. Seems to work. + http://clokep.blogspot.com/2013/10/yahoo-protocol-google-summer-of-code.html + http://lxr.instantbird.org/instantbird/source/chat/protocols/ + http://lxr.instantbird.org/instantbird/source/chat/protocols/xmpp/ - No OTR support yet + OTR support tickets: https://bugzilla.instantbird.org/show_bug.cgi?id=877 https://bugzilla.mozilla.org/show_bug.cgi?id=779052 + For a stopgap/prototype: We can use the js-ctypes wrapper of libotr along with the message observer API + Example observer API use w/ rot13: http://hg.instantbird.org/addons/file/tip/rot13 + JS-Ctypes wrapper for native libotr: http://gitorious.org/fireotr/fireotr/blobs/master/chrome/content/otr_wrappe… + The ctypes wrapper can be converted to an XPCOM wrapper later. + According to sshagarwal #maildev on irc.mozilla.org, Mozilla is also working towards implementing all of the primitives needed for OTR (and OTR itself) in NSS. These are listed in this comment: https://bugzilla.mozilla.org/show_bug.cgi?id=779052#c17 + We could also rely on the ctypes wrapper until native support is available, and possibly skip an XPCOM libotr wrapper entirely. + Solid proxy support. JS XMPP implementation allows you to omit DNS SRV and since everything goes through nsIChannels, proxy support is easy to verify and audit. + Messaging window is jailed to type=content (unlike cryptocat) and is additionally XSS filtered immediately prior to display: https://mxr.mozilla.org/comm-beta/source/chat/modules/imContentSink.jsm Summary of Goals Met: Release a secure, portable chat program that sends all traffic over Tor: + Yes. Can be used with a wide variety of chat networks: + Yes, even without libpurple Uses off-the-record encryption of conversations by default: - Not yet, but support is coming, and it's not too hard to deploy a stopgap French, Spanish, and Arabic support: * Partly yes. Full support for French and Spanish, but Instandbird has no translations for Farsi or Arabic (however Thunderbird does support these locales and can also be used as a chat client). -- Mike Perry

3 2

Attentive Otter IM bundle update
by Tom Lowenthal 09 Oct '13

09 Oct '13

We had a meeting as scheduled at 1100h Pacific. We broadly agreed that: * we don't want to use Pidgin/libpurple * we have a mild preference for Instantbird. We have some open questions about Instantbird: 1. What sort of attack surface does Instantbird present, compared to -- say -- a browser. 2. What's the timeline for Instantbird implementing OTR, and how are they going about it. Our current plan is to go for a more thorough investigation of Instantbird, and work out what we'd need to do to take Instantbird and produce Tor Messenger, and what roadblocks stand in our way. We were unable to find a lead for this project during the meeting. Afterwards, Arlo volunteered to put together such a plan, and possibly even execute it. Arlo has committed to putting that plan together by the end of the weekend. If we allow Monday morning to read and digest Arlo's work, we should reconvene some time on Monday afternoon, Tuesday, or Wednesday next week. [Let me know when you're free.][1] I've decided to send out updates to both tor-dev and tor-assistants, as well as to the individual addresses of folks who are interested. I'm committed to using the string "Otter" and "Attentive" in the subject line. If you want to get those emails, please [edit the wiki page][2] to add that info. I've only put my info there for now, so please edit it if you want to get personal attention in future emails. What you should do now: 1. Please [tell me about your availability][1] to meet next week. 2. Please add your name, preferred email, and IRC nick to the appropriate section of the [Attentive Otter wiki page][2]. [1]: http://doodle.com/g7xq4e2x8pgf7vda [2]: https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter/Attentive On 9 October 2013 09:04, Tom Lowenthal <me(a)tomlowenthal.com> wrote: > 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

1 0

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