[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-dev] Attention Otters



Not sure the following is entirely clear or complete,
but I tried to capture the concerns from the meeting
and the ensuing discussion.

Hope it helps.

Arlo



Attentive Otter Plan
====================
 
Goal
----
 
Add instant-messaging to the Tor browser bundle in order to provide a secure
communication tool which supports the free flow of information online.
 
Overview
--------
 
Instantbird [1] is a cross-platform IM client based on Mozilla's XULRunner.
The following presents the necessary steps to turn Instantbird into the
future Tor Messenger.
 
A Way Forward
-------------
 
1. Remove libpurple dependence
 
This is a trivial amount of work and changes to the build to support it would
be accepted upstream. They are already considering moving libpurple, and the
added protocols it supports, to an add-on for reasons of licensing/code
quality. JS implementations of the following protocols exist: XMPP, Google
Talk, Facebook, IRC, Twitter, with Yahoo landing soon and AIM/ICQ started but
further away.
 
2. OTR support
 
Instantbird currently lacks support for OTR. Two pieces are needed here: a
suitable OTR implementation, and an interface between the client and that
library (essentially, the role that pidgin-otr plays).
 
To get started, for the OTR library, a js-ctypes wrapper of libotr should be
used in conjunction with the message observer API. Code [2] from a few years
ago towards this end has been written but probably needs to be dusted off and
extended. An effort is underway at Mozilla to implement OTR in JS using NSS,
which could be dropped in as a replacement. A patch has been submitted [3] but it looks far from complete, so I wouldn't expect it anytime soon. When asked, they said it won't be ready for *a while*. Should the NSS implementation fail to materialize entirely, they would still be willing to take the
ctypes wrapper and libotr, as it doesn't present any licensing issues. In his
analysis, Mike suggested converting the ctypes wrapper to an XPCOM
wrapper but it's unclear why that's preferable.

The front-end side seems like a larger undertaking. This involves not only
the interaction with the message observer API but handling the quirks in the
various protocols (think /me in IRC), authentication including SMP, and
importing and storing long-term keys. Sukhe estimated at least a month of
development time and expressed an interest in being the one to undertake it.
 
On the bright side, the Instantbird team seems eager for OTR support and this
work will most likely be upstreamed.
 
3. Disable logging
 
An add-on may be required to ensure certain desirable configurations, like
logging disable by default. A difference in goals between UX for the
average user and the TIMBB user may force us to maintain these changes.
 
4. Tor controller
 
Tor Launcher will be used as the controller. Sukhe has already reported
having this working.
Using only JS protocol implementations means all traffic goes through
nsIChannels, making proxy support fairly easy to verify. For DNS,
network.proxy.socks_remote_dns should be set. DNS SRV should not be an issue
seeing as how it isn't supported by Mozilla [4]. Should test for other
UDP traffic leaks.
 
5. Messaging window
 
Jail it to type=content. Preferably everything is displayed in plaintext,
with HTML disabled or at least sanitized with an XSS filter [5]. Disable JS
and other features. Make use of all the preferences from TorBirdy.
 
6. Installer and updates
 
Leverage the work that's already being done on Mozilla's updater for the TBB.
 
7. Deterministic builds
 
Deterministic builds for the TBB was a major undertaking. I can't imagine
this case being any different, less the experience and groundwork already
laid.
 
8. Sandboxing
 
Come up with a practical, cross-platform way to sandbox the application.
I don't have an answer here. Maybe you do.
 
9. Audit
 
- Instantbird's render attack surface (content window, XSS filter, etc.)
- Crypto in NSS and how JS uses it
- Interface between the UI and OTR
- Proxy by-pass
- And more ...
 
10. Translations
 
Instantbird is available in 14 languages, including French and Spanish.
However, none are RTL and we want to support Arabic and Farsi. Messaging
should already work for RTL languagues though, they've fixed a few bugs
to ensure it, and reflecting the UI is reported to not be a ton of work.
They are definitely willing to accept patches here.
 
11. Other considerations
 
- Disable Instantbird's built-in auto-updater and crash reporter
- For sure OTR on by default, but maybe disallow any non-OTR comm. entirely
- CA verification: TOFU mode? Pin popular domains?
- Disable older TLS/SSL suites
- Consider the interaction between all three Tor bundles (FF, TB, IM). Tor
Launcher could attempt to authenticate and read settings from an already
running control port.
- Choose a different default profile folder (to avoid picking up plugins
and other unsafe settings)
 
References
----------
 
[1] http://instantbird.com/
[2] https://gitorious.org/fireotr/fireotr
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=779052#c20
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=14328
[5] https://mxr.mozilla.org/comm-beta/source/chat/modules/imContentSink.jsm
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev