tor-dev March 2015

tor-dev@lists.torproject.org

76 participants
78 discussions

Different Key Fingerprints for Tor Browser?
by Florian Rüchel 05 Mar '15

05 Mar '15

Hey, just downloaded Tor Browser and noticed that most of the fingerprints on the page " 0x4E2C6E8793298290". However, under "Mac OS X and Linux" it reads " Erinn Clark signs the Tor Browsers. Import her key (0x416F061063FEE659) ". Shouldn't this be updated to the other fingerprint as well oder am I missing something? Regards, Florian

2 1

Re: [tor-dev] TBB for Ubuntu Touch?
by Nathan Freitas 05 Mar '15

05 Mar '15

On Thu, Mar 5, 2015, at 12:54 AM, CJ wrote: > Hello, > > I just saw Ubuntu Touch might be installed on some devices, for example > a nexus7, or nexus4, or nexus10. > > Is there anything to do in order to get TBB on Ubuntu Touch, knowing > it's a more or less standard Linux system? Did anyone tried it? You can definitely get tor running as a binary, but the low-level OS is actually more closely based on Android, and the window manager layer in Ubuntu Touch is quite different from the desktop version. > > I think I'll give a try to Touch on my nexus 7 — might be the time to do > some tests regarding Tor on this kind of OS ;). Give it a try - who knows what might be possible. Ubuntu Touch is definitely a platform I am excited about too! +n

1 0

Porting Tor Browser to the BSDs
by Libertas 03 Mar '15

03 Mar '15

Has anyone looked into this? I talked to the maintainer of the OpenBSD Firefox port, but he wasn't very interested and pointed out the difficulty caused by the deterministic build system. I can verify that it doesn't work out of the box, but haven't had time to play with it much more than that. I think that the Tor Browser is an increasingly important tool, and that it's a problem that it isn't available on the BSDs. Thoughts? Suggestions?

5 8

RFC: Tor Messenger Second Alpha
by Sukhbir Singh 03 Mar '15

03 Mar '15

Hi, Tor Messenger is an instant messaging client currently under development. It is designed to make connections using the Tor network and will therefore be a valuable piece in the privacy-enhancing software toolkit (web: Tor Browser, email: Thunderbird + TorBirdy, chat: Tor Messenger.) Based on the Instantbird IM client [0], Tor Messenger: - sends all traffic over Tor, - uses Off-the-Record (OTR) encryption [1] of conversations by default, - can be used with a wide variety of chat networks, - has an easy-to-use graphical user interface localized into multiple languages. Some more information about Tor Messenger (and why we picked Instantbird) can be found on the wiki [2]. * Current Status We have Tor Messenger bundles for Linux (32-bit and 64-bit) with OTR (using ctypes-otr [4]) and Tor support (Tor binary and Tor Launcher included), among other privacy settings. We are doing automated builds of Tor Messenger using rbm [5] (thanks to Nicolas Vigier). @@@ WARNING: NOT READY FOR PUBLIC USE. DO NOT DISTRIBUTE. @@@ * Bundles Linux (32-bit) https://people.torproject.org/~sukhbir/tor-messenger-0.0.5/tor-messenger-0.… Linux (64-bit) https://people.torproject.org/~sukhbir/tor-messenger-0.0.5/tor-messenger-0.… sha256sum https://people.torproject.org/~sukhbir/tor-messenger-0.0.5/sha256sums.txt https://people.torproject.org/~sukhbir/tor-messenger-0.0.5/sha256sums.txt.a… The bundles are signed with the key 0xB297B391. Extract the bundles and then run: ./start-tor-messenger. This is an early release and there may be serious privacy leaks and other issues -- please DO NOT recommend Tor Messenger to end users; this release is only for developers and advanced users who would like to help us with testing but understand the risks involved with using alpha software. DO NOT ignore this warning. Notable changes since the last release include various privacy improvements, OTR UI enhancements and support for authentication via SMP. @@@ WARNING: NOT READY FOR PUBLIC USE. DO NOT DISTRIBUTE. @@@ * Feedback With this release, we invite feedback not limited to anonymity leaks, usability issues, feature requests and suggestions for improvement. Please submit your feedback using the bug tracker [3] (select the "Tor Messenger" component). You can also talk to us on this mailing list or on IRC. (No seriously, don't use the bundles for any serious communication yet.) [0] - http://instantbird.com/ [1] - https://otr.cypherpunks.ca/ [2] - https://trac.torproject.org/projects/tor/wiki/doc/TorMessenger [3] - https://trac.torproject.org/projects/tor/newticket [4] - https://github.com/arlolra/ctypes-otr [5] - http://rbm.boklm.eu/ Thanks, Arlo Breault and Sukhbir Singh

1 0

GSOC - Tor not selected this year?
by Frederic Jacobs 03 Mar '15

03 Mar '15

Hey Tor-Dev, I see there are a few proposals coming in for GSoC projects but browsing the list of selected projects, it does appear that Tor was not selected this year. (Neither is Mozilla <http://blog.queze.net/post/2015/03/03/Mozilla-not-accepted-for-Google-Summe…>). So unless I’m getting it wrong, I don’t think Tor will be part of GSoC this year :( Have a nice day everyone, Fred

1 0

Damian's Status Report - February 2015
by Damian Johnson 03 Mar '15

03 Mar '15

Why can't it always be winter? With murderous weather keeping you indoors life is so much more productive. -------------------------------------------------------------------------------- Hidden Service Descriptor Support -------------------------------------------------------------------------------- Stem now has the ability to read tor hidden service descriptors! https://trac.torproject.org/projects/tor/ticket/15004 This is moot for the moment as there isn't a method to get them, but with David's work on #14847 this is becoming a thing. -------------------------------------------------------------------------------- Google Summer of Code -------------------------------------------------------------------------------- Sadly we weren't accepted into GSoC 2015. The program was trimmed back this year from 190 to 137 orgs, with several veteran orgs dropped to make room for newcomers. We're in good company. Mozilla, Linux Foundation, Blender, and others were not included this year too. Friday we're gonna get tips to improve our chances next year. Pity, but c'est la vie. Regardless of GSoC we're always happy to welcome newcomers, so if you'd like to get involved then don't be shy! -------------------------------------------------------------------------------- Few other noteworthy things were... * Gautham added connection resolution support for Windows! (#14844) * Foxboron added Tox support for testing multiple python versions. (#14091) * Notified relays prior to tor 0.2.4.18 that they should upgrade. (#13555) * Worked with Sebastian and Roger on a couple tor segfauts I ran into. (#14803, #14901) * Ported Tor's argument handling tests to Stem. (#14109, #14806) Cheers! -Damian

1 0

Proposal 242: Better performance and usability for the MyFamily option
by Nick Mathewson 02 Mar '15

02 Mar '15

Filename: 242-better-families.txt Title: Better performance and usability for the MyFamily option. Author: Nick Mathewson Created: 2015-02-27 Status: Open 1. Problem statement. The current family interface allows well-behaved relays to identify that they all belong to the same 'family', and should not be used in the same circuits. Right now, this interface works by having every family member list every other family member in its server descriptor. This winds up using O(n^2) space in microdescriptors, server descriptors, and RAM. Adding or removing a server from the family requires all the other servers to change their torrc settings. One proposal is to eliminate the use of the Family option entirely; see ticket #6676. But if we don't, let's come up with a way to make it better. (I'm writing this down mainly to get it out of my head.) 2. Design overview. In this design, every family has a master ed25519 key. A node is in the family iff its server descriptor includes a certificate of its ed25519 identity key with the master ed25519 key. The certificate format is as in proposal 220 section 2.1. Note that because server descriptors are signed with the node's ed25519 signing key, this creates a bidirectional relationship where nodes can't be put in families without their consent. 3. Changes to server descriptors We add a new entry to server descriptors: "family-cert" This line contains a base64-encoded certificate as described above. It may appear any number of times. 4. Changes to microdescriptors We add a new entry to microdescriptors: "family-keys" This line contains one or more space-separated strings describing families to which the node belongs. These strings MUST be between 1 and 64 characters long, and sorted in lexical order. Clients MUST NOT depend on any particular property of these strings. 5. Changes to voting algorithm We allocate a new consensus method number for voting on these keys. When generating microdescriptors using a suitable consensus method, the authorities include a "family-keys" line if the underlying server descriptor contains any family-cert lines. For reach family-cert in the server descriptor, they add a base-64-encoded string of that family-cert's signing key. 6. Client behavior Clients should treat node A and node B as belonging to the same family if ANY of these is true: * The client has server descriptors or microdescriptors for A and B, and A's descriptor lists B in its family line, and B's descriptor lists A in its family line. * The client has a server descriptor for A and one for B, and they both contain valid family-cert lines whose certs are signed by the family key. * The client has microdescriptors for A and B, and they both contain some string in common on their family-cert line. 7. Deprecating the old family lines. Once all clients that support the old family line format are deprecated, servers can stop including family lines in their descriptors, and authorities can stop including them in their microdescriptors. 8. Open questions The rules in section 6 above leave open the possibility of old clients and new clients reaching different decisions about who is in a family. We should evaluate this for anonymity implications. It's possible that families are a bad idea entirely; see ticket #6676.

3 2

Relays that change their fingerprints a lot
by Philipp Winter 02 Mar '15

02 Mar '15

Inspired by Gareth's 31C3 talk [0], I taught sybilhunter [1] to calculate the amount of unique fingerprints a Tor relay used over time. Armed with that feature, I extracted the top 10 relay IP addresses that had the most fingerprints for every month since 2007 [2]. While most IP addresses show up only once in the monthly top 10, three IP addresses showed up more than ten times. Address Count Owner Total changes ---------------------------------------------------------------- 193.19.77.145 11 times ISP in France (DDO) 163 71.57.5.24 11 times ISP in the US (Comcast) 430 141.70.22.69 12 times University in Germany 293 Note that being present in the monthly top 10 isn't necessarily suspicious because it can be attributed to misconfiguration. For example, if a Tor process' data directory is set to /tmp, you get a new fingerprint every time you reboot. A better metric is the amount of unique fingerprints, so I extracted the IP addresses that changed their fingerprint the most [3]. One IP address in Comcast's network, 98.212.74.104, changed its fingerprint several hundred times. That happened from August to December 2010. Below is one of the relay's descriptors. Note that the nickname suggests that the relay was running on OpenWRT. @type server-descriptor 1.0 router openwrt 98.212.74.104 9001 0 0 platform Tor 0.2.1.26 on Linux mips opt protocols Link 1 2 Circuit 1 published 2010-09-10 01:42:42 opt fingerprint 90BD DDA6 D716 D36A D236 03A7 06A9 887E FFEE DFED uptime 915 bandwidth 102400 102400 55670 Unfortunately, it's difficult to make meaningful conclusions from this data. Relays that change their fingerprint a lot might still be honest unless the distribution of their fingerprints clearly deviates from a uniform distribution or correlates with Tor's DHT structure in some way. I also uploaded the raw data [4]. [0] <http://media.ccc.de/browse/congress/2014/31c3_-_6112_-_en_-_saal_2_-_201412…> [1] <https://gitweb.torproject.org/user/phw/sybilhunter.git/> [2] <http://www.nymity.ch/hunting_sybils/multiple_fingerprints/accumulated_top10…> [3] <http://www.nymity.ch/hunting_sybils/multiple_fingerprints/accumulated_top10…> [4] <http://www.nymity.ch/hunting_sybils/multiple_fingerprints/monthly-statistic…> Cheers, Philipp

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev March 2015