- tor-dev - lists.torproject.org

Tor Messenger Beta: Chat over Tor, Easily
by Sukhbir Singh 30 Oct '15

30 Oct '15

Hi, Today we are releasing a new, beta version of Tor Messenger, based on Instantbird [0], an instant messaging client developed in the Mozilla community. * What is it? Tor Messenger is a cross-platform chat program that aims to be secure by default and sends all of its traffic over Tor. It supports a wide variety of transport networks, including Jabber (XMPP), IRC, Google Talk, Facebook Chat, Twitter, Yahoo, and others; enables Off-the-Record (OTR) Messaging [1] automatically; and has an easy-to-use graphical user interface localized into multiple languages. * What it isn't... Tor Messenger builds on the networks you are familiar with, so that you can continue communicating in a way your contacts are willing and able to do. This has traditionally been in a client-server model, meaning that your metadata (specifically the relationships between contacts) can be logged by the server. However, your route to the server will be hidden because you are communicating over Tor. We are also excited about systems like Pond [2] and Ricochet [3], which try to solve this problem, and would encourage you to look at their designs and use them too. * Why Instantbird? We considered a number of messaging clients: Pidgin, Adam Langley's xmpp-client, and Instantbird. Instantbird was the pragmatic choice -- its transport protocols are written in a memory-safe language (JavaScript); it has a graphical user interface and already supports many natural languages; and it's a XUL application, which means we can leverage both the code (Tor Launcher) and in-house expertise that the Tor Project has developed working on Tor Browser with Firefox. It also has an active and vibrant software developer community that has been very responsive and understanding of our needs. The main feature it lacked was OTR support, which we have implemented [4] and hope to upstream to the main Instantbird repository for the benefit of all Instantbird (and Thunderbird) users. * Current Status Today we are releasing a beta version with which we hope to gain both usability and security related feedback. There have been three previous alpha releases to the mailing lists that have already helped smooth out some of the rougher edges. * Downloads Linux (32-bit) https://dist.torproject.org/tormessenger/0.1.0b2/tor-messenger-linux32-0.1.… Linux (64-bit) https://dist.torproject.org/tormessenger/0.1.0b2/tor-messenger-linux64-0.1.… Windows https://dist.torproject.org/tormessenger/0.1.0b2/tormessenger-install-0.1.0… OS X https://dist.torproject.org/tormessenger/0.1.0b2/TorMessenger-0.1.0b2-osx64… sha256sums https://dist.torproject.org/tormessenger/0.1.0b2/sha256sums.txt https://dist.torproject.org/tormessenger/0.1.0b2/sha256sums.txt.asc The sha256sums.txt file containing hashes of the bundles is signed with the key 0x6887935AB297B391 (fingerprint: 3A0B 3D84 3708 9613 6B84 5E82 6887 935A B297 B391). * Instructions - On Linux, extract the bundle(s) and then run: ./start-tor-messenger.desktop - On OS X, copy the Tor Messenger application from the disk image to your local disk before running it. On all platforms, Tor Messenger sets the profile folder for Firefox/Instantbird to the installation directory. - Note that as a policy, unencrypted one-to-one conversations are not allowed and your messages will not be transmitted if the person you are talking with does not have an OTR-enabled client. You can disable this option in the preferences to allow unencrypted communication but doing so is not recommended. * Source Code We are doing automated builds [5] of Tor Messenger for all platforms. The Linux builds are reproducible: anyone who builds Tor Messenger for Linux should have byte-for-byte identical binaries compared with other builds from a given source. You can build it yourself [6] and let us know if you encounter any problems or cannot match our build. The Windows and OS X builds are not completely reproducible yet but we are working on it [7]. * What's to Come Our current focus is security, robustness and user experience. We will be fixing bugs and releasing updates as appropriate, and in the future, we plan on pairing releases with Mozilla's Extended Support Release (ESR) cycle. We have some ideas on where to take Tor Messenger but we would like to hear what you have to say. Some possibilities include: - Reproducible builds for Windows and OS X (#10942) - Sandboxing (#10943) - Automatic updates (#14388) - Improved Tor support (#10950) - OTR over Twitter DMs (#13312) - Produce (and distribute) internationalized builds (#10945) - Secure multi-party communication (np1sec) [8] - Encrypted file-transfers - Usability study * How To Help Give it a try and provide feedback, requests, and file bugs [9] (choose the "Tor Messenger" component). If you are a developer, help us close all our tickets [10] or help us review our design doc [11]. As always, we are idling on IRC in #tor-dev (OFTC) (nicks: arlolra; boklm; sukhe) and subscribed to the tor-talk/dev mailing lists. Please note that this release is for users who would like to help us with testing the product but at the same time who also understand the risks involved in using beta software. Thanks and we hope you enjoy Tor Messenger! [0] - http://instantbird.com [1] - https://otr.cypherpunks.ca [2] - https://pond.imperialviolet.org [3] - https://ricochet.im [4] - https://github.com/arlolra/ctypes-otr [5] - https://gitweb.torproject.org/tor-messenger-build.git [6] - https://gitweb.torproject.org/tor-messenger-build.git/tree/README [7] - https://trac.torproject.org/projects/tor/ticket/10942 [8] - https://github.com/equalitie/np1sec [9] - https://trac.torproject.org/projects/tor/newticket [10] - https://trac.torproject.org/projects/tor/query?status=!closed&component=Tor… [11] - https://trac.torproject.org/projects/tor/wiki/doc/TorMessenger/DesignDoc

2 3

[Applications Team] First meeting next Tuesday 19:00 UTC
by Georg Koppen 29 Oct '15

29 Oct '15

Hi, just a reminder that the applications team is starting the monthly meetings next week on Tuesday, November 3 at 19:00 UTC[0] in #tor-project on irc.oftc.net. The proposed topic is still talking about UX/internationalization issues. If there are other things worth discussing we can easily amend the agenda at the beginning of the meeting. See you there, Georg [0] Originally I had written "18:00 UTC" but I forgot to take the end of the summer time into account.

1 0

Re: [tor-dev] Pluggable Transports v1 spec rewrite.
by Nathan Freitas 29 Oct '15

29 Oct '15

On Thu, Oct 29, 2015, at 09:19 AM, Yawning Angel wrote: > Hello all, > > In an attempt to make Pluggable Transports more accessible to other > people, and to have a spec that is more applicable and useful to other > projects that seek to use Pluggable Transports for circumvention, I have > drafted a re-write of the spec. > > This is not intended to alter existing behavior, but instead make it > clear that the whole "Pluggable Transports" thing isn't just for Tor. > > Unless people have serious objections, this will replace the existing > PT spec, to serve as a stop-gap while the next revision of the PT spec > (that does alter behavior) is being drafted/implemented. > Any small or big changes to highlight that push us to the more accessible goal?

2 1

Re: [tor-dev] Pluggable Transports v1 spec rewrite.
by Hugo Maxwell Connery 29 Oct '15

29 Oct '15

Hi, A commendable effort. It is both deserved and pleasant that Tor hold the "gold standard" for a low latency, privacy enhancing, distributed, collaborative network. A perhaps more crowning achievement could be the fostering of a diverse ecosystem of related technologies. This effort continues to signal the Tor community's belief in open, free(dom), collaboration in the space. Hats off ! Hugo ________________________________________ Date: Thu, 29 Oct 2015 13:19:01 +0000 From: Yawning Angel <yawning(a)schwanenlied.me> To: tor-dev(a)lists.torproject.org Subject: [tor-dev] Pluggable Transports v1 spec rewrite. Message-ID: <20151029131901.3bbe0a20(a)schwanenlied.me> Content-Type: text/plain; charset="us-ascii" Hello all, In an attempt to make Pluggable Transports more accessible to other people, and to have a spec that is more applicable and useful to other projects that seek to use Pluggable Transports for circumvention, I have drafted a re-write of the spec. This is not intended to alter existing behavior, but instead make it clear that the whole "Pluggable Transports" thing isn't just for Tor. Unless people have serious objections, this will replace the existing PT spec, to serve as a stop-gap while the next revision of the PT spec (that does alter behavior) is being drafted/implemented. Regards, -- Yawning Angel

1 0

Reminders: this week's Tor dev meeting is still at 1330 UTC today
by Nick Mathewson 28 Oct '15

28 Oct '15

Hi! Reminder 1: There is a weekly meeting where we talk about development progress on the program "tor". Reminder 2: It has been at 1330 UTC; it is still at 1330 UTC for this week. (Remember, some of the world has made DST changes, but not all of the world.) Reminder 3: It will be at a different time (TBD) next week. Thanks, all! -- Nick

1 0

TB 5.0.3 for OpenBSD released
by attila 28 Oct '15

28 Oct '15

The Tor BSD Diversity Project (TDP) is proud to announce the release of Tor Browser (TB) version 5.0.3 for OpenBSD. TDP (https://torbsd.github.io) is an effort to extend the use of the BSD Unixes into the Tor ecosystem, from the desktop to the network. The 5.0.3 release is the sixth release of the Tor Browser from TDP. To install TB for OpenBSD, please see http://mirrors.nycbug.org/pub/snapshots/packages/amd64/README if you are running OpenBSD -current on amd64. TDP is focused on diversifying the Tor network, with TB being the flagship project. Additional efforts are made to increase the number of *BSD relays on the Tor ntwork. Since its launch in March 2015, TDP has made significant contributions. In addition to the TB releases, both BSDCan and BSDCon Brasil featured TDP-focused meetings. In early October, the TDP focused presentation (http://www.queair.net/br-pres) prompted a significant increase in Tor relays in Brazil. Before the presentation, there were around 22 Tor relays, all of which were Linux in addition to two Windows nodes. In the weeks after the presentation, several new *BSD Tor relays appeared, accounting for up to 35% of bandwidth provided by new Tor relays in Brazil. Finally, TDP is working to convince BSD-using businesses to follow Mozilla's December 2014 example to run Tor relays. At this point, New York Internet has commited to running two high-bandwidth relays, one FreeBSD and the other OpenBSD, at its facility in Bridgewater, New Jersey. TDP's source code repository resides at http://github.com/torbsd. If you want to build the ports from source under OpenBSD-current the current tarball is available at http://bits.haqistan.net/~attila/tbb.tgz Feel free to bug me if you need help (contact infos on my home page: http://trac.haqistan.net/~attila) TDP is seeking funding to continue and extend its efforts. Please contact us if interested in assisting TDP, allowing us to dedicate more time to the project. Pax, -A -- http://trac.haqistan.net | attila(a)stalphonsos.com | 0xE6CC1EDB

2 1

Feedback on CollecTor web redesign
by Karsten Loesing 28 Oct '15

28 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi devs, I just finished a redesign of the CollecTor website and would appreciate your feedback: https://metrics.torproject.org/index2.html For reference, the old CollecTor website is still available here: https://metrics.torproject.org/index.html https://metrics.torproject.org/formats.html Let me add that I'm not a web designer, and let me prove that statement by telling you that <i>all</i> HTML on that website was written using vim. I'm more than happy to accept patches or suggestions, though I'll likely ask you to explain them to me. Thanks! All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWJpaaAAoJEJD5dJfVqbCr8/YIAIimH7j5Z2qr7OwfhBrH20MJ fNoBEdFBjSveWTYsB/77yZx1mEtDTXI/FCCQM5AURmE82SUJQ1Ocumn+J2mVgdmh hobxFrQBnsSWdK0qDtyNc7U5oDX7P6ruoBdfwBtFppXpp/VHkFsU0TIiMxcqGcUH yuHzRlaSIUpOXzaFl4STeEM9zmFqaR8+qayteWrWQpLMHf3SOksXKcr14+8CZmsl C7YopnoLqglo0dQA9FjM3U+w9MnEoHHskN4Yl4ZkQFGYPziqNRFTHmvCoKEMUz3u 0o1Emcmxc9jaZbyBU8Vbh474uEXM2ZtWSlMUt9M3dBRkIyuHy6lcBMS5q3i2wXc= =hHc4 -----END PGP SIGNATURE-----

5 9

[Metrics Team] Metrics Team mailing list and Metrics Team wiki page
by Karsten Loesing 28 Oct '15

28 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Metrics Team members, hello devs, the Metrics Team now has a team wiki page and a team mailing list: https://trac.torproject.org/projects/tor/wiki/org/teams/MetricsTeam https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team As described on the wiki page, the mailing list "is public in the sense that anyone can subscribe and read archives. But it's moderated on first post, meaning that your first post will be reviewed to make sure it's not spam and on topic and all further posts will go directly to the list. Feel free to subscribe and just listen if you want, and feel free to post if you have a question that you think is on topic." Everyone here should feel free to subscribe if they're interested in Metrics Team discussions. We should still move all discussions that are interesting to more people in Tor than just the Metrics Team to the tor-dev@ mailing list. Let's see how this works out. Note that future announcements, including meeting reminders, will go to the metrics-team@ list. (FWIW, there will be NO meeting tomorrow but next week.) All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWMIJHAAoJEJD5dJfVqbCrpZcIALEmgZuRxflQHm5mTYhevYAn T5+tbclKDjjo3hfVmMdQOTtJFkLzkoO/jX4zTTuRiN3O+3jtcAcAtQ/xLLxA/wP3 wMJ76aRe6GIJ7lfO1+GQGKQCO1wO8lWDrY5vEr3yARWZB2KiSaFfWofe7nHq1G2V HjlUz+JeuAEWsLTxlkq+g3nrLpGtsEip3h85NA7pIicik35D1/W7S3jy/L1UKKO9 noH2QUBbQpfO0oW+Tjq+aYLO7hp98ThNO6JFDVM5tVOoDsxAnlMWtJQihDAlK7b0 5+sH6ixYBuvOOvoOCRl/3DJqTuQO+IpCcAGI7qLJOpMCIrAcsq0Lwaz5tJrieSk= =8Zhk -----END PGP SIGNATURE-----

1 0

1-1-1 task exchange meeting on Thursday, Oct 29, 15:00 UTC in #tor-dev
by Karsten Loesing 28 Oct '15

28 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello devs, we'll have another 1-1-1 task exchange meeting on Thursday, October 29, 2015, 15:00 UTC in #tor-dev https://www.timeanddate.com/worldclock/fixedtime.html?iso=20151029T15 Note how this may be a different time in your timezone based on the insight that we have all saved enough daylight for the year. Quick reminder: The idea of the 1-1-1 task exchange meeting is that participants get 1 minute to describe a task that would take somebody else roughly 1 hour and that they will do within 1 week. It could be to review a document, write some analysis code, fix a small bug, and so on. It's best to come prepared with a task or two to get the most out of this. In a perfect world people would give one task for each task they take, but that is not required. https://trac.torproject.org/projects/tor/wiki/doc/1-1-1-task-exchange Talk to you tomorrow. All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWMHz2AAoJEJD5dJfVqbCr5e8H/3hPCDeEmrXuzEX4UZXxHoa+ RAsl5RN/Q2XFXMFayxno5BaGRBclusCDlbadOHcBcJeaZmETrfLmV1pN4OJA0yO9 RpNMcujl5VdOJSNcw5zxXn+QnHQPEqOUX4wFXuj/1BoAVRaek43IuqPTDTECNMRh 92vMaSJIQWxtudk5h0qhzB+DAEJSyTAU3gHH1yFecOITT2Nr69h6//WJIVn83rKW ViwLkQ4CoRfpp3aXyNRmMBEFj08bx09EAhI7bEkXYKf5oug5S/ah/YmHkHtfq+2D L9iz6vV/DdgXja/kcjMkakUvRAcSZPdNmmJwAqym2jCk+8FN9MsLW1ktL/R12xQ= =wU4R -----END PGP SIGNATURE-----

1 0

Desired exit node diversity
by grarpamp 28 Oct '15

28 Oct '15

On Wed, Sep 23, 2015 at 8:44 AM, tor-dev had: > I agree with Roger that ideally all relays can be exits (and since > we're being ideal, we'll assume that 'exit' means to every port). And > the network location distribution of relays by bandwidth is > proportional to both the client destination selection over time and > general Internet traffic over time, which match each other since we're > being ideal, and also matter since we're using an ideal trust-aware path > selection algorithm. And network wide route selection is such that > there is no congestion (generalizing Roger's assumption of infinite > exit capacity). Guessing that... assuming you can ship and calculate all the relay data / DHT / weights / KEX / circuits / preferences without bogging down your network or cpu... More relays being exits yields higher maximum possible path diversity. More relays being exits yields higher potential aggregate throughput between the network and clearnet. More exits yields broader more complete location overlay relavent to users (more relays yields more guards), datacenteres, and clearnet services (though there's as yet no attempt to exit near a service unless done manually). However when subject to global passive adversary tapping lots of the fiber, and you turn up more relays as exits (which are also non-exit relays by nature), you're adding lots more unused bandwidth over the same current consumption, leading to lots of unused quiet portions of the network. Which seems a greater potential for the adversary to "look, user just shot a unique traffic pattern completely through the quiet zone, gotcha". Whereas when the network links are full with clocked traffic (and fill traffic if there would otherwise be slack space) that observation attack is hardly as possible, to relavently impossible. If true, it seems to me adding more [non] exits should be pegged to some metrics and solicited on need / planning rather than turning up 6000 exits all at once. > In our ongoing work on trust-aware path selection, we assume a trust > distribution that will be the default used by a Tor client if another > distribution is not specified. (Most users will not have a reasoned > understanding of who they actually need to worry most about, and even > if they somehow got that right would not have a good handle how that > adversary's resources are distributed.) We call this adversary "The > Man", who is equally likely to be everywhere (each AS) on the > network. For relay adversaries, we assume that standing up and running > a relay has costs so weight a bit to make relays that have been around > a long time slightly more likely to be trusted. tor-relays had talk of individual humans keyparty signing their relays and including that WOT along with other trust and meta metrics in the consensus or other queryable datastore that could be used by the user to select preferred relay sets in whichever sensible or silly ways suited them. An adversary standing up relays has costs. Adversaries standing their human agents in public, even if their undercover is maintained, has additional costs and risks. > You > would then be faced with the political nightmare of issuing default > policies that tells users they should route with a weighting that says > country foo has an x percent chance of being your adversary, but > country bar has a y percent chance. (Likewise also have similar > statements that substitute 'large multinational corp.', 'major > criminal organization', 'specific big government agency that is > getting all the press lately' etc. for "country" in the last > sentence.) ======== In a sense this is like the original 'valid' flag, which you got by mailing me and having me manually approve your relay (and without which you would never be used as the entry or exit point in a circuit). Periodically I wonder if we should go back to a design like that, where users won't pick exit relays that don't have the "socially connected" badge. Then I opt against wanting it, since I worry that we'd lose exactly the kind of diversity we need most, by cutting out the relays whose operators we don't know. But both sides of that are just guessing. Let's find out! ======== These type of things may be better suited to a system where the users contribute their research and knowledge about the network into the network metadata db, and the users can query it to make their own decisions, follow other users prebuilt selection templates, or stick with the provided defaults.

3 3