- tor-dev - lists.torproject.org

REMINDER: Boisterous Otters helpdesk meeting in 1h
by Tom Lowenthal 15 Oct '13

15 Oct '13

Today at 1100h Pacific (an hour from now), we'll be in #tor-dev to discuss how we're going to start offering webchat support, in line with the [draft][1] produced by Colin (Phoul), with help from Lunar and Erinn (Helix). See y'all soon! -Tom [1]: https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter/Boisterous…

1 0

OnionMail 0.1.1 Beta is Out
by Liste 15 Oct '13

15 Oct '13

Next week we will translate the web site. http://onionmail.info/

1 0

ACTION REQUESTED: Help me plan deliverables for Sponsor F, Year 4 [due Friday, discussion Monday]
by Tom Lowenthal 14 Oct '13

14 Oct '13

<https://pad.riseup.net/p/Vt0TDXcdH0PB_Tor-Sponsor-F_Year-4> Sponsor F year 3 ends at the end of this month. Fear not though, for year 4 starts right after that! We need to get to work planing the things that we'll do during year 4, so that we can tell Sponsor F what they are and all that good stuff. For your convenience, I have prepared a [RiseUp pad][1] where we can put all our ideas (no I don't have an [AllOurIdeas][2] instance). For convenience and expediency, I would very much like it if you could get your ideas into this pad before **Friday 2013-10-18**. Then folks can look at them over the weekend, and we can talk about it next **Monday 2013-10-21, from 1100-1230h Pacific**. If you are in the `to` field, that's because I have some particular reason to believe that you are likely to be involved in year 4 (probably because you were in year 3). You should totes make sure you get your plan into the pad. To get started, you should head over to the [pad][1] and add your thoughts. Any questions? -Tom [1]: https://pad.riseup.net/p/Vt0TDXcdH0PB_Tor-Sponsor-F_Year-4 [2]: http://www.allourideas.org/

1 0

Stem Release 1.1
by Damian Johnson 14 Oct '13

14 Oct '13

Hi all. After seven months of work I'm pleased to announce Stem's 1.1.0 release! For those who aren't familiar with it, Stem is a Python library for interacting with Tor. With it you can script against your relay, descriptor data, or even write applications similar to arm and Vidalia. https://stem.torproject.org/ So what's new in this release? ============================================================ * Remote Descriptor Fetching The stem.descriptor.remote module allows you download current Tor descriptor data from directory authorities and mirrors, much like Tor itself does. With this you can easily check the status of the network without piggybacking on a local instance of Tor (or even having it installed). https://stem.torproject.org/api/descriptor/remote.html For example... from stem.descriptor.remote import DescriptorDownloader downloader = DescriptorDownloader() try: for desc in downloader.get_consensus().run(): print "found relay %s (%s)" % (desc.nickname, desc.fingerprint) except Exception as exc: print "Unable to retrieve the consensus: %s" % exc ============================================================ * Connection Resolution One of arm's most popular features has been its ability to monitor Tor's connections, and stem can now do the same! Lookups are performed via seven *nix and FreeBSD resolvers, for more information and an example see... https://stem.torproject.org/tutorials/east_of_the_sun.html#connection-resol… ============================================================ * Numerous Features and Fixes For a rundown of other changes see... https://stem.torproject.org/change_log.html#version-1-1 Cheers! -Damian

1 0

Checking Tonga's consensus (was: Consensus issues)
by Karsten Loesing 14 Oct '13

14 Oct '13

On 10/14/13 6:45 AM, metrics wrote: > WARNING: The consensuses published by the following directory authorities are more than one hour old and therefore not fresh anymore: Tonga Hi Damian, why do you check Tonga's consensus? Tonga is not a v3 directory authority but just a directory mirror. All the best, Karsten

2 1

More Hidden Services help needed: Guard enumeration
by George Kadianakis 14 Oct '13

14 Oct '13

Greetings, another important Hidden Service issue, is the guard enumeration attack that was described by the "Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization" paper (in section VII) [0]. A trac ticket was created to fix this issue (#9001 [1]). The most popular solution so far seems to be the 'Virtual Circuit' concept. The idea here is that if you have already created a circuit to a Rendezvous Point, and then that circuit fails and you need to connect to a different RP, then maybe you could reuse the previous hops of the circuit and only change the last hop to the new RP. This is an interesting concept and useful in other occasions too. For example, if the network is flooded with CREATE cells (like during the recent botnet invasion) and relays reject them because of increased workload, then maybe clients shouldn't build entirely new circuits to send CREATE cells to different relays (because building new circuits increases the total load of the network even more). However, this concept must be designed carefully and in a security-conscious way. Reusing parts of old circuits to connect to new nodes might result in unexpected attacks. More solutions have been proposed in #9001, like "guard node layers", which need further investigations. If you think you can contribute to this topic, please write your ideas in this mailing list or in ticket #9001. Enjoy. [0]: www.ieee-security.org/TC/SP2013/papers/4977a080.pdf‎ [1]: https://trac.torproject.org/projects/tor/ticket/9001

1 0

Re: [tor-dev] [linux-elitists] Browser fingerprinting
by Eugen Leitl 14 Oct '13

14 Oct '13

----- Forwarded message from katana <katana(a)riseup.net> ----- Date: Mon, 14 Oct 2013 09:27:41 +0200 From: katana <katana(a)riseup.net> To: cypherpunks(a)cpunks.org Subject: Re: [linux-elitists] Browser fingerprinting Message-ID: <525B9CED.20907(a)riseup.net> User-Agent: Thunderbird Hi, > Check out firegloves. It's outdated, and I'd love to see it getting > some love, but it's a great POC for anti-fingerprinting in Firefox. In <http://www.cosic.esat.kuleuven.be/publications/article-2334.pdf> about their FPDetective Framework <http://homes.esat.kuleuven.be/~gacar/fpdetective/>, the authors wrote about Firegloves: "Additionally, Firegloves limits the number of fonts that a single browser tab can load and reports false dimension values for the offsetWidth and offsetHeight properties of HTML elements to evade JavaScript-based font detection. We evaluated the effectiveness of Firegloves’ as a countermeasure to fingerprinting, and discovered several shortcomings. For instance, instead of relying on offsetWidth and offsetHeight values, we could easily use the width and the height of the rectangle object returned by getBoundingClientRect method, which returns the text’s dimensions, even more precisely than the original methods. This enabled us to detect the same list of fonts as we would without the Firegloves extension installed. Surprisingly, our probe for fonts was not limited by the claimed cap on the number of fonts per tab. This might be due to a bug, or to changes in the Firefox extension system that have been introduced after FireGloves, which is not currently being maintained, was first developed. Although Firegloves spoofs the browser’s user-agent and platform to pretend to be a Mozilla Firefox version 6 running on a Windows operating system, the navigator.oscpu is left unmodified, revealing the true platform. Moreover, Firegloves did not remove any of the new methods intro- duced in later versions of Mozilla Firefox and available in the navigator object, such as navigator.mozCameras and navigator.doNotTrack." I add: OK, the naviagtor.oscpu issue can be fixed easily, but the timezone feature doesnt't work too with enabled JavaScript. --- Katana ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

2 1

Attention Otters
by Arlo Breault 14 Oct '13

14 Oct '13

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

1 0

Chutney
by Charlie Belmer 11 Oct '13

11 Oct '13

Hey everyone, I am running some Chutney tests, and I want to go deeper than just running the bootstrap script and watching logs. Does anyone have advice on how to get the most out of Chutney? Thanks! Charlie

2 1

Pluggable transport biweekly meeting - Friday Oct 11
by vmonmoonshine＠gmail.com 11 Oct '13

11 Oct '13

Just a gentle reminder that the PT meeting is today in few hours: Friday - Oct 11 at CEST: 18:00 BST (Summer GMT): 17:00 UTC: 16:00 EST: 12:00 MNT: 10:00 PST: 9:00 @ #tor-dev on irc.oftc.net asn is going to moderate the session. (I have a very slow connection but I'll try to join) See you all there, Vmon

1 0