tor-dev

tor-dev@lists.torproject.org

5 participants
3594 discussions

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

Fwd: Tor Weather - bug in email text
by Pablo Brasero Moreno 27 Feb '15

27 Feb '15

Hello all, I recently found a small problem with Tor Weather, and I wasn't sure what can be done to get it fixed. I hope this is the right forum. The problem is in the "[Tor Weather] Confirmation Successful" email, and it's about the links on the body. Specifically, these links and the text descriptions next to them are mixed up. Where it says "change your Tor Weather notification preferences here", the link presented is the unsubscribe link. Likewise with the "unsubscribe" text and the preferences link. Incidentally, I've been looking for the code repository, but what I found ( https://gitweb.torproject.org/weather.git) has different messages. Is this the actual repo? Regards, -- Pablo Brasero Moreno pablo(a)pablobm.com

1 0

tor and libressl
by Tyrano Sauro 27 Feb '15

27 Feb '15

I got tor build with libressl. it works. Is this a good idea? TY

4 5

Priorities for Onionoo development
by Karsten Loesing 25 Feb '15

25 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi iwakeh, cc'ed Tor devs, now that we're down to 0 defect tickets in the Onionoo component (not counting that one ticket in needs_review that I hope to resolve before the weekend), ... time for a little applause... I went through the 20 open Onionoo enhancement tickets in an attempt to categorize and prioritize them. Mind going through the list below and commenting on summaries and priorities? And is there a ticket that you'd want to work on? Here's the list, where (--) means low priority and (++) means high priority: === Functional enhancements, user-facing features === #9778 Adding votes documents to Onionoo (-) Processing votes and adding a new document type are major enhancements. The result might turn out to be really useful, but this takes quite some effort. Not super urgent, I'd say. #11041 Add new document type with monthly relay and bridge statistics to Onionoo (-) This is a major feature, and I didn't hear back from the people who originally suggested it. I'd say put on hold until somebody really wants this. #11430 Add new field last_running for "seen in a network status with the Running flag" in addition to last_seen for "seen in a network status" (-) Not many people will care about this distinction, though it's technically a good thing to make it. #11432 Start a bridge's uptime history when it was first listed in a status Similar to #11430, not many people will care about this. But it's still a good idea. #13137 Historical data (+) Without reading the whole ticket, this sounds worthwhile, though time-consuming. #13424 Add new `descriptor` parameter that returns relays or bridges by digest of recently published descriptors This feature would only be used by a very small subset of people, though those people help debug the Tor network. Maybe this isn't terribly difficult to implement. #13425 Add new document type `debug` that includes digests of recently published descriptors and statuses they're referenced from (--) Unclear if people would actually use this. Lowest priority. #14879 add platform search support to onionoo (+) Useful feature, but we should first think about related features and whether we should add them at the same time. === Refactorings, documentation, non-functional enhancements === #11573 Ponder using a database for Onionoo rather than keeping indexes in memory and contents on disk (--) I don't see the clear advantage of switching to a database. There's the risk that it will not perform (much) better or even worse than the file system based design. In any case, we can easily spend lots and lots of hours on this, and even if we're successful, there's no/hardly any visible change to users. Lowest priority. #12944 onionoo protocol/client api and base implementaion (-) I'm unclear what the benefit will be. And unfortunately, patches have aged quite a bit by now. #13003 Figure out a better strategy to avoid concurrent Onionoo executions (+) Unclear what's left to do here, but the summary sounds reasonable. #13080 Add Ant tasks for measuring coverage, dependencies, etc. (++) Without reading the ticket body, this would be great to have. #13088 Versioning and Releases (++) Sounds like a great thing to do, but I need help with this. #13334 improve DetailsDocument (-) Subticket to #12944, same priority. #13362 Make Onionoo's logs more useful (-) Unclear what's left to do, though making logs more useful sounds good. Depending on how much time we can sink into this, though. #13561 logging documentation (-) Seems useful, but if we start documentation logging configuration, we'll soon write much more documentation. This can of course be useful. But it's a huge time sink. #13562 additional logging for backend and frontend components (-) Better log statements would be great, but see the concerns about related tickets. #13600 Improve bulk imports of descriptor archives (+) We're in a good position to complete this ticket. And while it only affects very few people (Onionoo operators), it's worthwhile. #13616 define jmeter testcase(s) ant ant task(s) (+) Sounds useful to have some baseline data and then see how performance changes as new features are added. #14201 Configure out/ directory path somewhere else than in web.xml. (+) Sounds trivially useful. And here's the Trac query that this list is based on: https://trac.torproject.org/projects/tor/query?status=!closed&status=!needs… By the way, thanks for all your hard work by submitting and reviewing Onionoo patches! Many people use your work every day without even knowing it. All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJU7ebnAAoJEJd5OEYhk8hIUOYH/3AP2iu8hnCYtbcDOSkzqbDT rSe/S5MewtrRlD4cnZID/TqGXGZLJofWbd4Ly4SOg0QpoT8uq47k/vmbeeOBXSqx O3Qxu/e7L9z8/NJeuym3nwTAcFnIQv7K1JkqvPSyB8wrMFhJe+mll+UHS38f5C4z dKdCLs5gsmGJljqbr17tMr2y0hm38u1ID8lzlqmU3H/vI+5dvKK7DPfdsRNLbvmc tA5ATufehYya3xbHJPy8K9W0P706n3Dg4qHBrZ2AnxB4mmX/k3x842WJhnIYapyI kPiM2i2RVdumZA91kHUEu2dYMY0P3OzJK3K9cn9eNFtxMhnMmI1zttkOsIg7mWw= =ZHaC -----END PGP SIGNATURE-----

1 0

Hello, I am a Tor user in China.
by Li Xiaodong 25 Feb '15

25 Feb '15

Hello, I am a Tor user in China. When will StegoTorus be deployed on Tor software? Thank you very much.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev