- tor-dev - lists.torproject.org

Update on Roadmaps for Core Tor, Hidden Services and Tor Obfuscation
by Isabela 11 Mar '15

11 Mar '15

Hello everyone. In Valencia dev meeting we did an exercise to help create a roadmap (1yr) for the different Tor projects and organizational work. I've collected those roadmaps and published them here: https://trac.torproject.org/projects/tor/wiki/org/roadmaps (I will be sending a similar email to the other dev and org teams as well. ) What I would like to ask from the folks in this list, and who collaborate with*Core Tor, Hidden Services and Tor Obfuscation (PT, BridgeDB etc), *is to look at the tables for March and April and fill up the empty cells for: * sponsor -> is the task related to a sponsor? (or could be) * who -> person(s) who the task should be assigned to * tickets -> ticket(s) related to the task (please create them if appropriate) * date -> estimation dates are always good :) nickm has already created tickets for Core Tor tasks (Thanks Nick!) Let me know if you have questions. Here are the tables I am talking about: * March and April for Core Tor: https://trac.torproject.org/projects/tor/wiki/org/roadmaps/CoreTor * March and April for Hidden Services: https://trac.torproject.org/projects/tor/wiki/org/roadmaps/HS * March and April for Tor Obfuscation: https://trac.torproject.org/projects/tor/wiki/org/roadmaps/TorObfuscation thanks everyone, Isabela

1 0

Suggestions for Hidden Services Statistics Project
by Gautham Nekkanti 11 Mar '15

11 Mar '15

Hi, I have already shared my project idea on a Simple analytics tool for Hidden service providers. I am looking for suggestions and input from users who have had experience in hosting hidden services. Obviously, there would all useful traffic related statistics. I'm looking for suggestions on what tor-specific statistics do you think would be helpful? As meejah suggested, we are thinking on including a few tor-specific statistics like 'How many times their onion descriptor was requested', 'No of bytes transferred through circuits', e.t.c. Thanks

2 1

Two protocols to measure relay-sensitive hidden-service statistics
by A. Johnson 10 Mar '15

10 Mar '15

Hello tor-dev, While helping design ways to publish statistics about hidden services in a privacy-preserving manner, it has become clear to me that certain statistics cannot be safely reported using the current method of having each relay collect and report measurements. I am going to describe a couple of simple protocols to handle this problem that I think should be implementable without much effort. I'd be happy to get feedback in particular about the security or ease-of-implementation of these protocols. Two HS statistics that we (i.e. people working on Sponsor R) are interested in collecting are: 1. The number of descriptor fetches received by a hidden-service directory (HSDir) 2. The number of client introduction requests at an introduction points (IPs) The privacy issue with #1 is that the set of HSDirs is (likely) unique to an HS, and so the number of descriptor fetches at its HSDirs could reveal the number of clients it had during a measurement period. Similarly, the privacy issue with #2 is that the set of IPs are (likely) unique to an HS, and so the number of client introductions at its IPs could reveal the number of client connections it received. A approach to solve this problem would be to anonymize the reported statistics. Doing so raises a couple of challenges, however: 1. Anonymous statistics should be authenticated as coming from some relay. Otherwise, statistics could be polluted by any malicious actor. 2. Statistical inference should be made robust to outliers. Without the relay identities, it will be difficult to detect and remove values that are incorrect, whether due to faulty measurement or malicious action by a relay. I propose some simple cryptographic techniques to privately collect the above statistics while handling the above challenges. I assume that there exists a set of Statistics Authorities (StatAuths), of which at least one must be honest for the protocol to be secure, but all of which can be "curious" (that is, we want to maintain privacy from them as well and allow their action to be completely public). The Directory Authorities could serve as StatAuths. A single server could as well, if you trust it to be honest- but-curious. If you have a trusted non-curious server, things become much simpler, of course: just have relays report their values to the server and then have it publish a global aggregate only. The AnonStats1 protocol to privately publish both statistics if we trust relays not to pollute the statistics (i.e. #2 is not a problem) is as follows: 1. Each StatAuth provides 2k partially-blind signatures on authentication tokens to each relay in a consensus during the measurement period. The blind part of a signed token is simply a random number chosen by the relay. The non-blind part of a token consists of the start time of the current measurement period. The 2k tokens will allow the relay to submit k values to the StatAuths. Note that we could avoid using partially-blind signatures by changing keys at the StatAuths every measurement period and then simply providing blind signatures on random numbers. 2. At the end of the measurement period, for each statistic, each relay uploads the following each on its own Tor circuit and accompanied by a unique token from each StatAuth: 1. The count 2. The ``statistical weight'' of the relay (1/(# HSDirs) for statistic #1 and the probability of selection as an IP for statistic #2) 3. The StatAuths verify that each uploaded value is accompanied by a unique token from each StatAuth that is valid for the current measurement period. To infer the global statistic from the anonymous per-relay statistic, the StatAuths add the counts, add the weights, and divide the former by the latter. The AnonStats1 protocol is vulnerable to a relay that publishes manipulated statistics (i.e. challenge #2). If this is a concern, the AnonStats2 protocol mitigates it by using a median statistic intead of a sum: 1. Relays are divided into b bins by consensus weight. The bins have exponentially-increasing length, and the rate of increase c is set such that the ith bin by increasing weights has at least r relays each of weight at least some minimum min_weight (say, r=500, min_weight=100). The first bin has weights in [0, min_weight), and the ith bin has weights in [min_weight*c^(i-2), min_weight*c^(i-1)). 2. Each StatAuth provides k partially-blind signatures on authentication tokens to each relay in a consensus during the measurement period. The blind part of a signed token is simply a random number chosen by the relay. The non-blind part of a token consists of the start time of the current measurement period and the bin containing the relay's consensus weight. 3. At the end of the measurement period, for each statistic, each relay divides each statistic by the relay's ``statistical weight'' (1/(# HSDirs) for statistic #1 and the probability of selection as an IP for statistic #2). The result is the relay's estimate of the global value of the statistic. The relay then uploads this value via a new Tor circuit, accompanied by a unique token from each StatAuth. 4. The StatAuths verify that each uploaded value is accompanied by a unique token from each StatAuth that is valid for the current measurement period and that contains the same relay-weight bin. To infer a final global statistic from the anonymous per-relay estimates, the StatAuths use the weighted median of the received estimates, where the weight of an estimates is taken to be the smallest value of its accompanying bin (i.e. the bin's left edge).

3 9

Using Traceroute for AS-Path prediction
by Simon Koch 10 Mar '15

10 Mar '15

I am a student at the saarland university and currently workin on my bachelor thesis concerning AS-path prediction using traceroute. I want to correlate open-source BGP data and corresponding traceroute measurements. In the end I want to argue whether or not traceroute can be valid tool for live as-path prediction based on the matching and representation of changes in the respective (AS-)routes over time. I already did a preliminary measurement during which I gathered 2 month worth of traceroute information to different tor-nodes and correlated them with the BGP data available at RIPE-RIS. It turned out, that routes predominantly matched and that a high percentage of bgp route changes were also present in traceroute routes. Though only a smaller number of traceroute route changes were present in bgp routes. This leads to the assumption that traceroute might be a good as-path measurement-tool, as it would be quite unlikely that BGP AS Paths would match AS paths derived from traceroute measurements if traceroute could not reliable measure them. This information was only inferred from only one measurement point, though. As this topic may also be of interrest to tor I was wondering if anyone had some opionions on the general idea or knew some papers/researcher which are on the same track. I already read: * Towards an Accurate AS-Level Traceroute Tool * Quantifying the Pitfalls of Traceroute in AS Connectivity * Inferring AS-level Internet Topology from Router-Level Path Traces * A Study on Traceroute Potential in Revealing the Internet AS-Level Topology * Mixing Biases: Structure Changes in the AS Topology Evolution but I have the nagging feeling that there should be more. Further I am looking for a way to establish more measurement points to ensure a diversity in the data collection. Those points have to be in AS-peers of either the route-views project (zebra routers) or RIPE-RIS so I can also access the corresponding MRT-Data. I figured that traceroute.org Looking Glass may provide a way of doing so, but I am afraid that the overlap of Looking Glass servers and public BGP-peers is very small. Any idea on how to establish diverse measurementpoints (maybe volunteers) would be greatly appreciated. Regards, Simon

3 2

Questions for the torflow developers
by Francois Valiquette 10 Mar '15

10 Mar '15

Hello, I am a master student in System Information Security in Canada and I am doing a project which will evaluate the security of the Tor Exit Nodes in a Tor user perspective. By reading the documentation of torflow, it is yet not clear to me, exactly which tests you are doing. One part of my project is to make a description of each possible attack an Exit Node can make and a description of a detection/mitigation mechanism for each of the attack but also I would like to implement one or more tests that have not been implemented by torflow. Here is a list of attacks that we think that a malicious Exit Node could do. The list is not complete, we will expand it. I would like to know, what type of attacks have you not tested and also, feel free to complete this list. -SSL and none SSL Sniffing (Session Hijacking, emails, web URL, IRC channel, FTP ) -Virus Injection (Linux, OSX, Windows, Android) -Misc Injection/Tampering: advertisements, JavaScript, etc -Pharming Attacks -DNS Rebinding -SSL MITM with CN -SSL MITM (revoked certificate, expired certificate and untrusted certificate) -SSL Downgrade attacks -SSL stripping -Dropping TLS connections -Spurious RST packets -Exploiting Bittorrent Tracker to reveal a user’s real IP Thank you for reading and sorry for the long post Frank

3 3

#9321 changes not included in tor-0.2.6.3-alpha changelog
by George Kadianakis 10 Mar '15

10 Mar '15

Hello Nick, I noticed that the 0.2.6.3 changelog does not contain the guardfraction blurb of #9321. I think this happened in c2312f4f5fbc37581180f53fb67edb70f3360104 where the bug9321 file was deleted but its contents were not added to the changelog. The text that is missing is: o Major features: - Introduce the Guardfraction feature which improves the load balancing of path selection towards guard nodes. Specifically, it aims to reduce the traffic gap that guard nodes experience when they first get the Guard flag. This is a required step if we want to increase the guard lifetime to 9 months or greater. Resolves ticket 9321. Maybe we should add it now even though the release has happened. Thanks!

2 1

Tor Project proposal for GSoC 2015
by Juro P. Doi 08 Mar '15

08 Mar '15

Hello, I would like to participate to the GSoC 2015 (my first one) and contribute to the Tor project. I am registered as timide on the OFTC IRC network. I am currently student in master of computer science, and working with LibFTE for a school project. Actually, fteproxy can be used as a Tor bridge in order to hide a Tor connection. To use this type of transport, one have to know the address of a remote fte proxy server or use an hardcoded one. I would like to improve the use of fteproxy in order that a client could use his own remote server or at the opposite could ask for one. The main idea is that server nodes announce themselves to a distributed service that clients could query. I already had some mail exchanges with the maintainer of the FTE tools, who advised me to post my proposal to the mailing list. It can be done at two different points: 1. into fteproxy so that it's Tor independant and any service that use fteproxy could benefit of it (as Tor) 2. into Tor so that all type of bridges could be shared Anouncements should be done over multiple protocols an queried with fallback by the clients. These methods could be over services known by hardcoded IP/URL or set by the user. Types of services could be: 1. services like https://gitweb.torproject.org/bridgedb.git 2. IRC 3. mail etc. What do you think about it? Thanks. Juro P. Doi

3 2

OONI weekly dev meeting today Monday 9th of March 18:00 UTC
by Arturo Filastò 08 Mar '15

08 Mar '15

Hello Oonitarians, As discussed during the last meeting we did not gather this week because of the OpenITP festival. It was a very fruitful and interesting event, that we should update people that could not attend about. We shall therefore gather at the usual 18:00 UTC (19:00 CET, 13:00 EST, 10:00 PST) on the #ooni channel on irc.oftc.net. See you soon! ~ Arturo

1 0

A Proposal for a hidden service revocation system
by Adrien Johnson 08 Mar '15

08 Mar '15

Filename: xxx-rend-revoke.txt Title: Hidden Service Revocation Author: Adrien Johnson Created: 2015-03-04 Status: Draft Hidden service operators need to be able to revoke trust in their hidden service if they know or suspect their hidden service secret key has been compromised. 1. Motivation A Hidden service operator can determine that the hidden service secret key is compromised in several ways today. Forensic traces of intrusion may be detected on the hidden service server, or valid signed descriptors for the service may be published by someone other than the legitimate operator in a traffic hijacking attack. It is impossible for a compromised hidden service secret key to be used to hijack traffic in a way that is not detectable by the latter method. Even though it is easy for the operator to detect a hidden service key is compromised, there is no satisfactory way for a hidden service operator to notify its users of this fact. The hidden service may display a message to its users warning of the compromise and directing them to a new supposedly uncompromised .onion domain, but a user has no way to know whether such a message was posted by the legitimate hidden service operator or a hijacker. A revocation system where anyone possessing the hidden service secret key can revoke trust in the key solves this problem. 2. Overview This revocation system is built on the hidden service directory system. A revocation takes the form of a hidden service descriptor which provides no way to contact the hidden service (i.e. zero introductory points). A hidden service directory which receives a revocation descriptor and verifies its signature should discard any non-revocation descriptors it possesses for that hidden service, and should propagate the revocation through the hidden service directory system as normal. Crucially, a hidden service directory which possesses a revocation descriptor for a hidden service and receives a newer, valid descriptor for that hidden service which is not a revocation descriptor MUST retain the revocation descriptor and MUST discard the newer non-revocation descriptor. This is the only change needed to support this revocation system at a basic level today. 3. Design considerations 3.1 Revocation lifetime Ideally, a revocation should be permanent. The Tor network would ideally remember forever that a hidden service has been revoked, and this would provide the maximum possible protection to the users of the hidden service against imposter services. Indeed, any tor node which becomes aware a hidden service has been revoked should remember this information forever, and should refuse to connect to any hidden service which it knows was revoked in the past (unless the user disables this protection). However, a permanent (or even just long-lived) revocation in the hidden service directories present problems: 1) Increased memory and bandwidth requirements on the Tor network compared to a normal hidden service descriptor. For non-malicious use, this may not really be a problem, since once a service is revoked, there would be only a trickle of requests for updated information about it (from visitors who have not already found out it was revoked). However for a malicious user who attacks the Tor network by flooding it with hidden service descriptors for fake hidden services, any increased lifetime of a revocation descriptor over a normal descriptor represents a multiplication of their attack power. 2) For next generation hidden services as described in 224-rend-spec-ng.txt, a revocation which lasts longer than one blinded signing key validity period weakens the privacy protection against correlation which is provided by rotating blinded signing keys. If a revocation were - for any amount of time - not expected to be signed by the current normal blinded signing key for that service, but instead a separate 'blinded revocation signing key', then users seeking to check the revocation status of that service before visiting would have to make two requests for a hidden service descriptor: one to see if there is a revocation descriptor published by that service, and one to see if there is a normal descriptor published by that service. A malicious hidden service directory (or group of directories) could use this correlation to determine which hidden service descriptors belong to the same hidden service between blinded signing key rotations. [NOTE: Not sure how easy correlation based on request volume already makes this attack if the attacker controls enough hidden server directories to reliably monitor request volume between blinded signing key rotations. I suspect the real danger of long-lived revocations compared to attacks based purely on request volume is that it lets attackers easily "pick up a lost trail" if they managed to link a revocation signing key and a normal blinded signing key at any time in the past, whereas attacks based purely on request volume are likely to lose track of a service permanently when its descriptors shift to a directory the attacker does not control] For these reasons, revocations which last no longer than a normal hidden service descriptor, and which the operator must therefore constantly broadcast, are the safest option for implementing hidden service revocations using hidden service descriptors. Short lived revocations have the advantage that the Tor network does not need to make any hard-and-fast judgement about how long it is worthwhile to remember a hidden service has been revoked, the hidden service operator can make that judgement for themselves and broadcast the revocation for as long the operator feels hijacking and impersonation is a concern. If the operator is unable to maintain (or fears they will be unable to maintain) a revocation broadcast for an appropriate amount of time, they can disclose their private key to a 3rd party service who will broadcast the revocation on the operator's behalf. An operator would want to employ several of these services, since if only one service had the private key, and if they were malicious, they could cease broadcasting the revocation and instead use the key to set up an impostor service. Despite these minor difficulties that short-lived revocations impose, they are still a major improvement to the security of the Tor network. 3.2 Digression on the shape of a 3rd party Revocation Broadcast Service Though it is outside the scope of this proposal, I envision these 3rd party key revocation services being simple websites where anyone can upload a hidden service private key and the website will broadcast the revocation indefinitely. They could employ simple abuse-mitigation like CAPCHAs or IP ratelimiting over the clearnet to prevent mass-upload of keys. This should keeps costs low enough that these revocations services could operate for free. Alternatively (or additionally), a distributed 3rd party revocation service could be built into the Tor network by enclosing the private key in the revocation descriptor. This would allow anyone who retrieves the revocation descriptor (and knows which .onion it's for) to broadcast updated 'echo' revocation descriptors of their own. This could be built to avoid the problems with static long-lived revocations. [TODO: Expand in another document later] 4. Implementation 4.1 Basic Support For the Tor network to support hidden service revocations at a basic level, a large proportion of hidden service directories must recognize that a hidden service descriptor with zero introductory points has the special meaning of being a revocation. These hidden service directories must not allow a current unexpired revocation descriptor to be replaced by a non-revocation descriptor (so called 'un-revocation'). In all other ways, treatment of a revocation descriptor is identical to treatment of a non-revocation descriptor for a hidden service. [NOTE: Maybe we want a more explicitly requested revocation? Using a zero introductory point descriptor as a revocation has the advantage of being backward-compatible with older directory software, which will be able to accept and propagate the revocation to other more up-to-date directories, even though the older directories will not provide protection against un-revoking a hidden service if the attacker delivers an un-revocation descriptor to them directly. Is there a need for zero introductory point descriptors in any other case? If a hidden service previously published introductory points and it now no longer can be contacted at those points, and it does not have any new introductory points, it is unreachable. Publishing a descriptor announcing all zero of its introductory points will not change its reachability, though it may slightly reduce wasted effort by tor nodes attempting to reach it.] 4.1.1 Steps required to add support 1) If current code results in hidden services publishing zero- introductory point descriptors, this is blocked to prevent accidental revocation. I would love to get this in 0.2.6. 2) If a modification is needed in step 1, then a grace period is given for hidden service operators to update their software. This grace period does not have to be long, we can move onto step 3 relatively fast, since the only penalty for accidental revocation step 3 would create is forcing the hidden service to upgrade their software, and the hidden service being unreachable for a maximum of 25 hours (lifetime of a descriptor) after the hidden service upgrades. 3) Hidden service directories are modified to not allow a current unexpired revocation descriptor to be replaced by an un-revocation descriptor. Basic support for revocation is achieved! 4) A long upgrade grace period is now given. The vast majority of hidden services should be using software which includes the modifications made in step 1 5) Expanded revocation capabilities may be added, as described below. 4.2 Expanded Capabilities 4.2.1 Cache of revoked services A Tor node which tried to connect to a hidden service in the past and discovered that the service was revoked should remember that revocation and refuse to connect indefinitely, even if the revocation ceases to be broadcast in the future. 4.2.2 Presentation to the user If an onion proxy that detects the user tried to visit a revoked service, this information should be presented to the user out-of-band. I.E not in a way that could be mistaken for a hidden service which is only temporarily unreachable, or as information sent by the service. This could be done via a system level popup, or a taskbar notification. The presentation should be strongly distinguished from a hidden service which is simple unreachable. 4.2.3 Automatic hijacking detection/revocation Tor hidden service software could have a mode to detect if another party is using the hidden service private key to publish descriptors for that service. If the hidden service operator configures it, the Tor hidden service software could immediately begin to broadcast the revocation for that service. 5. Future Compatibility with Next Generation Hidden Services Next generation Tor hidden services require a modified revocation system because the hidden service master secret key is better protected, and does not need to live online on the hidden service tor node. The day-to-day operation of the service is carried out by a pre-loaded set of changing subordinate descriptor signing keys, which expire after a set time (25 hours by default). If descriptor signing keys are compromised, they can be used to hijack traffic and impersonate the hidden service, but only until the descriptor signing keys expire. So there is a need for a way to revoke descriptor signing keys and provide new ones, but not to permanently revoke trust in the hidden service. Also, theft of descriptor signing keys should not allow an attacker to revoke the master secret key. The revocation permissions would looks something like the following. (Blinded signing keys are equivalent to the master secret key for revocation purposes because an attacker which obtains any blinded signing secret key can easily derive the master secret key.) 1) Current descriptor signing key can revoke current descriptor signing key. 2) Master secret key can revoke any descriptor signing key and provide a new descriptor signing key for that time-period. 3) Master secret key is the only one that can revoke master secret key. 5.1 Descriptor Signing Keys Revoking Themselves [TODO: Finish later] 5.1 Master Secret Key Revoking and Replacing Descriptor Signing Keys [TODO: Finish later] 5.2 Master Secret Key Revoking Itself [TODO: Finish later]

2 2

bittorrent based pluggable transport
by Dan Cristian Octavian 07 Mar '15

07 Mar '15

Hello! My name is Dan, I've been working on a pluggable transport for Tor based on bittorrent as cover traffic and wanted to let you know about it. https://github.com/danoctavian/bit-smuggler In a nutshell, I'm tunnelling a data stream through a bittorrent peer connection that is created by real bittorrent clients (uTorrent for this implementation) - to avoid "parroting" traffic pitfalls and active probing. This made the implementation quite tricky to get right, so my reasoning is that it's a worthy trade-off. I worked with Dr. George Danezis as my supervisor for the project. He came up with the idea to try bittorrent, the crypto strategy and advised me throughout. The docs in the repo contain more information. I researched this topic for my master thesis, and the last 2 months i did a rewrite of the project. At the moment I did not integrate with Tor (working on an Extended orPort implementation) and I need to do more work on the server to make it run properly as a long running process. Please ask me anything for clarification and let me know how can i make this useful for the Tor project. Any kind of feedback is very welcome. I'm working a 9-5 starting next week, but I'm going to work on it in my spare time. Thanks!

6 13

Where can I find info for TunnelDirConns 0|1 ?
by HOANG NGUYEN PHONG 07 Mar '15

07 Mar '15

Dear all, I read a discussion about "How can Tor use a one hop circuit to a directory server during initial bootstrap?" here However, why I cannot find "TunnelDirConns 0|1" in torproject.org/docs/tor-manual.html.en? Is the feature already removed or replaced with another name? Next, may I ask that as Weasel mentioned in his answer for the question: "This so-called tunneled connection doesn't provide anonymity. It only provides confidentiality, i.e. nobody listening on your network can know exactly what you fetched" However, in Tor directory Protocol 3, there is a sentence "all directory information is uploaded and downloaded with HTTP" which means no encryption for what we fetch, so where is the "confidentiality"? Best Regard.

2 1

Patch to improve time-period interval changes in 224-rend-spec-ng.txt
by Adrien Johnson 07 Mar '15

07 Mar '15

Hello all, I have a patch for proposal 224-rend-spec-ng.txt that clarifies the definition of time periods and improves the behaviour when the time period duration needs to be changed. -Adrien Johnson

1 0

Tor Browser sha256 checksums for old versions?
by Griffin Boyce 07 Mar '15

07 Mar '15

Hey all, I was just wondering if it's possible to get a gpg-signed list of sha256 checksums for the Tor Browser. The website only shows the current version's list of hashes. Which is really useful, but it would be great to have them all if possible. thanks, Griffin -- “Sometimes the questions are complicated and the answers are simple.” ― Dr. Seuss

2 2

TBB for Ubuntu Touch?
by CJ 05 Mar '15

05 Mar '15

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? 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 ;). Cheers, C.

2 3

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 02 Mar '15

02 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